linux-kernel - Re: [PATCH 00/14] selftests/sgx: Oversubscription, page permission, thread entry

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]

Message-ID: <ee323912-ebb9-9262-a599-b7e22527f892@intel.com>
Date:   Thu, 16 Sep 2021 09:14:21 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>, <linux-sgx@...r.kernel.org>,
        <jarkko@...nel.org>, <shuah@...nel.org>
CC:     <seanjc@...gle.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
        <linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/14] selftests/sgx: Oversubscription, page permission,
 thread entry

Hi Dave,

On 9/16/2021 8:37 AM, Dave Hansen wrote:
> On 9/15/21 1:30 PM, Reinette Chatre wrote:
>> This series consists out of outstanding SGX selftests changes, rebased
>> and gathered in a single series that is more easily merged for testing
>> and development, and a few more changes added to expand the existing tests.
> 
> One other high-level thing we should probably mention: Building and
> running enclaves is a pain.  It's traditionally required a big SDK from
> Intel or a big software stack from *somebody* else.
> 
> This adds features like threads to the SGX selftest which are
> traditionally implemented in that big software stack.  This is a *good*
> thing since it helps test SGX kernel support with only code from the
> kernel tree.

Will do. Just to be clear this support for multiple threads is essential 
for exception handling testing. An exception that triggers an 
asynchronous exit from an enclave could be fixed from outside the 
enclave and then execution could return to the original thread, this is 
demonstrated and tested in patch 12/14. Alternatively, it may be needed 
to fix the issue that triggered the exception from _within_ the enclave. 
In the latter case the enclave should be entered at a new entry point 
(new thread/new Thread Control Structure(TCS)) from where the issue can 
be fixed before execution can continue in the original thread that 
triggered the exception. I have tests for this scenario.

> This is similar to what we did with MPX, which also typically required a
> big toolchain outside of the kernel.  Despite MPX's demise, I think this
> approach worked well, and I'm happy to see it replicated here.
> 
> Feel free to add my ack on the real (non-stub) patches in the series:
> 
> Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
> 

Thank you very much

Reinette