Message ID | cover.1631731214.git.reinette.chatre@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | selftests/sgx: Oversubscription, page permission, thread entry | expand |
On Wed, 2021-09-15 at 13:30 -0700, Reinette Chatre wrote: > Hi Everybody, > > 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. > > The outstanding SGX selftest changes included in this series that have already > been submitted separately are: > > * An almost two year old patch fixing a benign linker warning that is still > present today: > https://lore.kernel.org/linux-sgx/20191017030340.18301-2-sean.j.christopherson@intel.com/ > The original patch is added intact and not all email addresses > within are valid. > > * Latest (v4) of Jarkko Sakkinen's series to add an oversubscription test: > https://lore.kernel.org/linux-sgx/20210809093127.76264-1-jarkko@kernel.org/ > > * Latest (v2) of Jarkko Sakkinen's patch that provides provide per-op > parameter structs for the test enclave: > https://lore.kernel.org/linux-sgx/20210812224645.90280-1-jarkko@kernel.org/ > > The reason why most of these patches are outstanding is that they depend > on a kernel change that is still under discussion. Decision to wait in: > https://lore.kernel.org/linux-sgx/f8674dac5579a8a424de1565f7ffa2b5bf2f8e36.camel@kernel.org/ > The original patch for this kernel dependency continues to be included in > this series as a placeholder until the ongoing discussions are concluded. > > The new changes introduced in this series builds on Jarkko's outstanding > SGX selftest changes and adds new tests for page permissions, exception > handling, and thread entry. Thanks for including my patches into this! It's a good idea that we carry single series (and probably least confusing to Shuah). Thank you. /Jarkko
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. 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@linux.intel.com>
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@linux.intel.com> > Thank you very much Reinette
On Wed, 2021-09-15 at 13:30 -0700, Reinette Chatre wrote: > Hi Everybody, > > 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. > > The outstanding SGX selftest changes included in this series that have already > been submitted separately are: > > * An almost two year old patch fixing a benign linker warning that is still > present today: > https://lore.kernel.org/linux-sgx/20191017030340.18301-2-sean.j.christopherson@intel.com/ > The original patch is added intact and not all email addresses > within are valid. > > * Latest (v4) of Jarkko Sakkinen's series to add an oversubscription test: > https://lore.kernel.org/linux-sgx/20210809093127.76264-1-jarkko@kernel.org/ > > * Latest (v2) of Jarkko Sakkinen's patch that provides provide per-op > parameter structs for the test enclave: > https://lore.kernel.org/linux-sgx/20210812224645.90280-1-jarkko@kernel.org/ > > The reason why most of these patches are outstanding is that they depend > on a kernel change that is still under discussion. Decision to wait in: > https://lore.kernel.org/linux-sgx/f8674dac5579a8a424de1565f7ffa2b5bf2f8e36.camel@kernel.org/ > The original patch for this kernel dependency continues to be included in > this series as a placeholder until the ongoing discussions are concluded. > > The new changes introduced in this series builds on Jarkko's outstanding > SGX selftest changes and adds new tests for page permissions, exception > handling, and thread entry. > > Reinette > > Jarkko Sakkinen (9): > x86/sgx: Add /sys/kernel/debug/x86/sgx_total_mem > selftests/sgx: Assign source for each segment > selftests/sgx: Make data measurement for an enclave segment optional > selftests/sgx: Create a heap for the test enclave > selftests/sgx: Dump segments and /proc/self/maps only on failure > selftests/sgx: Encpsulate the test enclave creation > selftests/sgx: Move setup_test_encl() to each TEST_F() > selftests/sgx: Add a new kselftest: unclobbered_vdso_oversubscribed > selftests/sgx: Provide per-op parameter structs for the test enclave > > Reinette Chatre (4): > selftests/sgx: Rename test properties in preparation for more enclave > tests > selftests/sgx: Add page permission and exception test > selftests/sgx: Enable multiple thread support > selftests/sgx: Add test for multiple TCS entry > Sean Christopherson (1): > selftests/x86/sgx: Fix a benign linker warning > > Documentation/x86/sgx.rst | 6 + > arch/x86/kernel/cpu/sgx/main.c | 10 +- > tools/testing/selftests/sgx/Makefile | 2 +- > tools/testing/selftests/sgx/defines.h | 33 +- > tools/testing/selftests/sgx/load.c | 40 +- > tools/testing/selftests/sgx/main.c | 341 +++++++++++++++--- > tools/testing/selftests/sgx/main.h | 7 +- > tools/testing/selftests/sgx/sigstruct.c | 12 +- > tools/testing/selftests/sgx/test_encl.c | 60 ++- > .../selftests/sgx/test_encl_bootstrap.S | 21 +- > 10 files changed, 445 insertions(+), 87 deletions(-) > One test that would be also nice to have at some point would be vepc test. It's not exceptionally hard to ramp up KVM: https://lwn.net/Articles/658511/ Hmm... perhaps this type of kselftest should be part of the series that Paolo is upstreaming because otherwise we are dependent on non-upstream QEMU to test those changes. Looking back, this would have been already good idea to ramp up when the original KVM-SGX series was upstreamed because not that many have motivation to self-compile QEMU (I did but thinking about potential larger coverage). /Jarkko