aes-perf: sdp test: why secure input buffer is being fed with zero/random data? about optee_test HOT 5 CLOSED

As AES processing (encryption or decryption) does not depend on buffer content (AFAIK) i think this perf test would still be valid even if the input buffer is never initialized. This would prevent xtest from feeding a secure buffer :)

from optee_test.

Buffers that are under the secure data path are referenced by a file descriptor (input_sdp_fd here) instead of a (pre-mapped) buffer virtual address (in here). To be able to read or write to the buffer, one must map it hence the instructions you refer to.

from optee_test.

I understand that buffer under secure data path (i.e. secure buffer) are referenced by a fd and to access them, they must be mapped with mmap.

But, it is not clear, why secure buffer is being accessed (read/write) by non-secure aes-perf application in the first place?

I see, it is accessed by the application just to fill zero/random data in the secure buffer; it is unmapped immediately after that. But,I expect secure buffer to be inaccessible to the non-secure application.

from optee_test.

But,I expect secure buffer to be inaccessible to the non-secure application.

That is true but for test purpose maybe (likely in the current case) there is no effective memory firewall preventing non-secure from reading and/or writing to an SDP buffer. The xtest application here simulates an AES processing performed on a SDP buffer hence possibly feeding the SDP buffer from non-secure side before measuring how long it takes to invoke an AES processing on a SDP buffer by a TA.

from optee_test.

Thanks for clarification. We, in fact, have a situation, where we have restricted the secure buffer access to non-secure application. Based on clarification, it does not seem to be hard requirement to fill the input buffer for the speed test - hence we shall proceed by removing it.

from optee_test.