lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 12 May 2021 04:10:37 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Reinette Chatre <reinette.chatre@...el.com>
Cc:     Shuah Khan <shuah@...nel.org>, linux-sgx@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] selftests/sgx: Migrate to kselftest harness

On Tue, May 11, 2021 at 11:42:49AM -0700, Reinette Chatre wrote:
> Hi Jarkko,
> 
> On 5/7/2021 8:56 PM, Jarkko Sakkinen wrote:
> > Migrate to kselftest harness. Use a fixture test with enclave initialized
> > and de-initialized for each of the existing three tests, in other words:
> > 
> > 1. One FIXTURE() for managing the enclave life-cycle.
> > 2. Three TEST_F()'s, one for each test case.
> 
> These changes make it easier to add tests and I think it is a valuable
> addition.
> 
> > 
> > This gives a leaps better reporting than before. Here's an example
> > transcript:
> > 
> > TAP version 13
> > 1..3
> > 0x0000000000000000 0x0000000000002000 0x03
> > 0x0000000000002000 0x0000000000001000 0x05
> > 0x0000000000003000 0x0000000000003000 0x03
> > ok 1 enclave.unclobbered_vdso
> > 0x0000000000000000 0x0000000000002000 0x03
> > 0x0000000000002000 0x0000000000001000 0x05
> > 0x0000000000003000 0x0000000000003000 0x03
> > ok 2 enclave.clobbered_vdso
> > 0x0000000000000000 0x0000000000002000 0x03
> > 0x0000000000002000 0x0000000000001000 0x05
> > 0x0000000000003000 0x0000000000003000 0x03
> > ok 3 enclave.clobbered_vdso_and_user_function
> > 
> 
> The output claims to conform to TAP13 but it does not seem as though all of
> the output conforms to TAP13. I assume such output would confuse automated
> systems.

You mean

0x0000000000000000 0x0000000000002000 0x03
0x0000000000002000 0x0000000000001000 0x05
0x0000000000003000 0x0000000000003000 0x03

?

/Jarkko
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ