[0/4] selftests/sgx: Trigger the page reclaimer and #PF handler

Create a heap for the test enclave, which has the same size as all
available Enclave Page Cache (EPC) pages in the system. This will guarantee
that all test_encl.elf pages *and* SGX Enclave Control Structure (SECS)
have been swapped out by the page reclaimer during the load time. Actually,
this adds a bit more stress than that since part of the EPC gets reserved
for the Version Array (VA) pages.

For each test, the page fault handler gets triggered in two occasions:

- When SGX_IOC_ENCLAVE_INIT is performed, SECS gets swapped in by the
  page fault handler.
- During the execution, each page that is referenced gets swapped in
  by the page fault handler.

Jarkko Sakkinen (3):
  x86/sgx: Add sgx_nr_all_pages to the debugfs
  selftests/sgx: Assign source for each segment
  selftests/sgx: Trigger the reclaimer and #PF handler

Tianjia Zhang (1):
  selftests/sgx: Fix Q1 and Q2 calculation in sigstruct.c

 Documentation/x86/sgx.rst               |  9 +++++
 arch/x86/kernel/cpu/sgx/main.c          | 10 ++++-
 tools/testing/selftests/sgx/load.c      | 38 ++++++++++++++----
 tools/testing/selftests/sgx/main.c      | 42 +++++++++++++++++++-
 tools/testing/selftests/sgx/main.h      |  4 +-
 tools/testing/selftests/sgx/sigstruct.c | 53 +++++++++++++------------
 6 files changed, 120 insertions(+), 36 deletions(-)

On 7/5/21 7:36 AM, Jarkko Sakkinen wrote:
> Create /sys/kernel/debug/x86/sgx_nr_all_pages, which reports total

> number of EPC pages available in the system.

Could we flesh this out a bit, please?

What's the value here when userspace could just re-enumerate the EPC
size from CPUID?

I'd really appreciate if we could draw parallels between these additions
to the "SGX VM" and their analogs in the "core VM".  In this case, I
think the closest analog is probably "MemTotal" in /proc/meminfo.

Second, how is this going to be used?

Third, is this going to be the ABI forever?

On Tue, Jul 06, 2021 at 07:56:40AM -0700, Dave Hansen wrote:
> On 7/5/21 7:36 AM, Jarkko Sakkinen wrote:

> > Create /sys/kernel/debug/x86/sgx_nr_all_pages, which reports total

> > number of EPC pages available in the system.

> Could we flesh this out a bit, please?

> 

> What's the value here when userspace could just re-enumerate the EPC

> size from CPUID?

> 

> I'd really appreciate if we could draw parallels between these additions

> to the "SGX VM" and their analogs in the "core VM".  In this case, I

> think the closest analog is probably "MemTotal" in /proc/meminfo.

> 

> Second, how is this going to be used?

> 

> Third, is this going to be the ABI forever?


debugfs is never a stable abi.  If it is being used as such, then the
kernel code is wrong.  This better just be debugging stuff only.

thanks,

greg k-h

On Tue, Jul 06, 2021 at 07:56:40AM -0700, Dave Hansen wrote:
> On 7/5/21 7:36 AM, Jarkko Sakkinen wrote:

> > Create /sys/kernel/debug/x86/sgx_nr_all_pages, which reports total

> > number of EPC pages available in the system.

> Could we flesh this out a bit, please?

> 

> What's the value here when userspace could just re-enumerate the EPC

> size from CPUID?


My thinking is that it is better to use "kernel synthesized" value for the
EPC size, because kernel controls the EPC.

> I'd really appreciate if we could draw parallels between these additions

> to the "SGX VM" and their analogs in the "core VM".  In this case, I

> think the closest analog is probably "MemTotal" in /proc/meminfo.


Would make sense.

> Second, how is this going to be used?


SGX kselftest creates a heap, of which size is the same as the total size
of the EPC reported by the kernel.

> Third, is this going to be the ABI forever?


AFAIK, debugfs is not part of the ABI.

/Jarkko