Re: [PATCH v8 5/5] selftests/sgx: Refine the test enclave to have storage

Shuah Khan
2021-06-15T21:55:28Z

On 6/15/21 7:15 AM, Jarkko Sakkinen wrote:
> On Tue, Jun 15, 2021 at 04:14:02PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Jun 14, 2021 at 02:16:15PM -0600, Shuah Khan wrote:
>>> On 6/10/21 2:30 AM, Jarkko Sakkinen wrote:
>>>> Extend the enclave to have two operations: ENCL_OP_PUT and ENCL_OP_GET.
>>>> ENCL_OP_PUT stores value inside the enclave address space and
>>>> ENCL_OP_GET reads it. The internal buffer can be later extended to be
>>>> variable size, and allow reclaimer tests.
>>>>
>>>> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>>>> ---
>>>> tools/testing/selftests/sgx/defines.h | 10 ++++
>>>> tools/testing/selftests/sgx/main.c | 57 ++++++++++++++++++-----
>>>> tools/testing/selftests/sgx/test_encl.c | 19 +++++++-
>>>> tools/testing/selftests/sgx/test_encl.lds | 3 +-
>>>> 4 files changed, 74 insertions(+), 15 deletions(-)
>>>>
>>>
>>> Test output before applying the series:
>>>
>>> TAP version 13
>>> 1..1
>>> # selftests: sgx: test_sgx
>>> # Unable to open /dev/sgx_enclave: No such file or directory
>>> # 1..0 # SKIP cannot load enclaves
>>> ok 1 selftests: sgx: test_sgx # SKIP
>>>
>>> Test output after applying second patch
>>>
>>> selftests/sgx: Migrate to kselftest harness
>>>
>>> Output changes to the following. It doesn't look like the second
>>> patch adds any new tests. What is the point in running the tests
>>> that fail if /dev/sgx_enclave is missing.
>>>
>>> Unfortunately this series doesn't have a cover letter that explains
>>> what this series is doing. I don't like the fact that the test
>>> output and behavior changes when migrating the test to kselftest
>>> harness. Shouldn't the output stay the same as in skip the tests
>>> if /dev/sgx_enclave fails.
>>
>> I get what you are saying but actually I do not know how with
>> fixtures I can skip "the rest" when FIXTURE_SETUP() fails.
>>
>> The reason for the output below is that with fixtures for all
>> tests enclave is initialized for each test case. And it kind of
>> makes sense because all tests start from the clean expected
>> state.
>>
>> I don't how to do that with zero change in the output.
>>

Yeah. I took a look at the FIXTURE. Doesn't look like it is possible.

>> The reason to do this change is to make it easy to add more tests,
>> and return correct status codes to the framework.
>
> To add: everything I did I based purely to the existing kernel
> documentation, following the examples on how to use fixture.
>

I will pick these up and will add a note to the last commit that
output changes, so test rings that run kselftest are aware of the
change.

thanks,
-- Shuah