Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v38 00/24] Intel SGX foundations
@ 2020-09-15 11:28 Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
                   ` (23 more replies)
  0 siblings, 24 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, akpm, andriy.shevchenko, asapek,
	bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	sean.j.christopherson, tglx, yaozhangx

Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control.

There is a new hardware unit in the processor called Memory Encryption
Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define
one or many MEE regions that can hold enclave data by configuring them with
PRMRR registers.

The MEE automatically encrypts the data leaving the processor package to
the MEE regions. The data is encrypted using a random key whose life-time
is exactly one power cycle.

The current implementation requires that the firmware sets
IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can
decide what enclaves it wants run. The implementation does not create
any bottlenecks to support read-only MSRs later on.

You can tell if your CPU supports SGX by looking into /proc/cpuinfo:

	cat /proc/cpuinfo  | grep sgx

v38:
* Fast iteration because I had email server issues with v37. Using
  temporary SMTP for this (mail.kapsi.fi).
* Return -EINTR when no data is processed, just like read().
  https://patchwork.kernel.org/patch/11773941/
* Remove cruft from SGX_IOC_ENCLAVE_ADD_PAGES and fix the return value.
  https://lore.kernel.org/linux-sgx/20200915095450.GH3612@linux.intel.com/T/#mc643ef2ab477f5f7aa5d463d883d1308eb44d6f1

v37:
* Remove MODULE_*().
  https://lore.kernel.org/linux-sgx/20200825164412.GF12107@zn.tnic/
* Fix mmap() type check.
  https://lore.kernel.org/linux-sgx/20200827152051.GB22351@sjchrist-ice/
* Fix ioctl-number.txt.
  https://lore.kernel.org/linux-sgx/20200826145239.GC22390@zn.tnic/
* Fix SPDX identifier in arch/x86/include/uapi/asm/sgx.h
  https://lore.kernel.org/linux-sgx/20200826145239.GC22390@zn.tnic/
* Consistently document "@encl: an enclave pointer".
  https://lore.kernel.org/linux-sgx/20200826145239.GC22390@zn.tnic/
* Renamed SGX_IOC_ENCLAVE_SET_ATTRIBUTE as SGX_IOC_ENCLAVE_PROVISION and
  cleaned up associated code. Also fixed issues of code introduced too
  early that were caused by the split. Now it should be more streamlined.
  https://lore.kernel.org/linux-sgx/20200826145239.GC22390@zn.tnic/
* Fixed signed integer shift overflow:
  https://github.com/intel/linux-sgx-driver/pull/16/commits d27ca6071b2b28e2e789d265eda796dd9fc65a64
* Fixed off-by-one error in a size calculation:
  https://github.com/intel/SGXDataCenterAttestationPrimitives/commit/e44cc238becf584cc079aef40b557c6af9a03f38
* Rework vDSO API with a context structure for IO data.
  https://lore.kernel.org/linux-sgx/20200904104437.29555-1-sean.j.christopherson@intel.com/
* Refined commentary about retry-loop with ENCLS[EINIT] based on Sean's response.
  https://lore.kernel.org/linux-sgx/20200629152718.GA12312@linux.intel.com/
* Return positive number from SGX_IOC_ENCLAVE_ADD_PAGES indicating the
  number of pages processed and set a fixed 1MB limit for length. In addition,
  on interrupt, return 0 and number of processed pages instead of -EINTR.
  https://lore.kernel.org/linux-sgx/20200626153400.GE27151@zn.tnic/

v36:
* Make a self-contained mprotect() handler.
* Move from radix_tree to xarray, which is more modern and robust data
  structure for managing large sparse arrays. Rename encl->page_tree as
  encl->page_array.

v35:
* Add missing SGX_ENCL_DEAD check to sgx_ioctl().

v34:
* Remove SGX_ENCL_DEAD checks from ioctl.c, as the file is open while
  executing an ioctl.
* Split driver patch into base patch and one patch for each ioctl.
* Move encl->flags check to the beginning of each ioctl. Return
  consistently -EINVAL if they don't match the expected values. Before,
  sometimes -EFAULT was returned instead of -EINVAL.
* Rename vm_ops->may_mprotect as vm_ops->mprotect() and move the call
  right before call to mprotect_fixup().

v33:
* Rebased to v5.8-rc1. Given the core changes (mmap_lock and #DB
  handling), it made sense to update the series.
* Refined documentation about how remote attestation is done in SGX.

v32:
* v31 contained not fully cleaned up main.c after merger of main.c and
  reclaim.c. Fixed in this version.
* Rebased to v5.7. Forgot to do this for v31.

v31:
* Unset SGX_ENCL_IOCTL in the error path of checking encl->flags in order
  to prevent leaving it set and thus block any further ioctl calls.
* Added missing cleanup_srcu_struct() call to sgx_encl_release().
* Take encl->lock in sgx_encl_add_page() in order to prevent races with
  the page reclaimer.
* Fix a use-after-free bug from the page reclaimer. Call kref_put() for
  encl->refcount only after putting enclave page back to the active page
  list because it could be the last ref to the enclave.
* Filter any CPU disallowed values from sigstruct->vendor
  SGX_IOC_ENCLAVE_INIT.
* Use bits 0-7 of page descriptor for the EPC section index. This
  should be enough for long term needs.
* Refined naming for functions that allocate and free EPC pages to
  be more sound and consistent.
* Merge main.c and reclaim.c into one.

v30:
Bunch of tags added. No actual code changes.

v29:
* The selftest has been moved to selftests/sgx. Because SGX is an execution
  environment of its own, it really isn't a great fit with more "standard"
  x86 tests.

  The RSA key is now generated on fly and the whole signing process has
  been made as part of the enclave loader instead of signing the enclave
  during the compilation time.

  Finally, the enclave loader loads now the test enclave directly from its
  ELF file, which means that ELF file does not need to be coverted as raw
  binary during the build process.
* Version the mm_list instead of using on synchronize_mm() when adding new
  entries. We hold the write lock for the mm_struct, and dup_mm() can thus
  deadlock with the page reclaimer, which could hold the lock for the old
  mm_struct.
* Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g. anonymous) can
  be used to reserve the address range. Now /dev/sgx supports only opaque
  mappings to the (initialized) enclave data.
* Make the vDSO callable directly from C by preserving RBX and taking leaf
  from RCX.

v28:
* Documented to Documentation/x86/sgx.rst how the kernel manages the
  enclave ownership.
* Removed non-LC flow from sgx_einit().
* Removed struct sgx_einittoken since only the size of the corresponding
  microarchitectural structure is used in the series ATM.

v27:
* Disallow RIE processes to use enclaves as there could a permission
  conflict between VMA and enclave permissions.
* In the documentation, replace "grep /proc/cpuinfo" with
  "grep sgx /proc/cpuinfo".

v26:
* Fixed the commit author in "x86/sgx: Linux Enclave Driver", which was
  changed in v25 by mistake.
* Addressed a bunch of grammar mistakes in sgx.rst (thanks Randy once
  again for such a detailed feedback).
* Added back the MAINTAINERS update commit, which was mistakenly removed
  in v25.
* EREMOVE's for SECS cannot be done while sanitizing an EPC section. The
  CPU does not allow to remove a SECS page before all of its children have
  been removed, and a child page can be in some other section than the one
  currently being processed. Thus, removed special SECS processing from
  sgx_sanitize_page() and instead put sections through it twice. In the
  2nd round the lists should only contain SECS pages.

v25:
* Fix a double-free issue when SGX_IOC_ENCLAVE_ADD_PAGES
  fails on executing ENCLS[EADD]. The rollback path executed
  radix_tree_delete() on the same address twice when this happened.
* Return -EINTR instead of -ERESTARTSYS in SGX_IOC_ENCLAVE_ADD_PAGES when
  a signal is pending.
* As requested by Borislav, move the CPUID 0x12 features to their own word
  in cpufeatures.
* Sean fixed a bug from sgx_reclaimer_write() where sgx_encl_put_backing()
  was called with an uninitialized pointer when sgx_encl_get_backing()
  fails.
* Migrated /dev/sgx/* to misc. This is future-proof as struct miscdevice
  has 'groups' for setting up sysfs attributes for the device.
* Use device_initcall instead of subsys_initcall so that misc_class is
  initialized before SGX is initialized.
* Return -EACCES in SGX_IOC_ENCLAVE_INIT when caller tries to select
  enclave attributes that we the kernel does not allow it to set instead
  of -EINVAL.
* Unless SGX public key MSRs are writable always deny the feature from
  Linux. Previously this was only denied from driver. How VMs should be
  supported is not really part of initial patch set, which makes this
  an obvious choice.
* Cleaned up and refined documentation to be more approachable.

v24:
* Reclaim unmeasured and TCS pages (regression in v23).
* Replace usages of GFP_HIGHUSER with GFP_KERNEL.
* Return -EIO on when EADD or EEXTEND fails in %SGX_IOC_ENCLAVE_ADD_PAGES
  and use the same rollback (destroy enclave). This can happen when host
  suspends itself unknowingly to a VM running enclaves. From -EIO the user
  space can deduce what happened.
* Have a separate @count in struct sgx_enclave_add_pages to output number
  of bytes processed instead of overwriting the input parameters for
  clarity and more importantly that the API provides means for partial
  processing (@count could be less than @length in success case).

v23:
* Replace SGX_ENCLAVE_ADD_PAGE with SGX_ENCLAVE_ADD_PAGES. Replace @mrmask
  with %SGX_PAGE_MEASURE flag.
* Return -EIO instead of -ECANCELED when ptrace() fails to read a TCS page.
* In the reclaimer, pin page before ENCLS[EBLOCK] because pinning can fail
  (because of OOM) even in legit behaviour and after EBLOCK the reclaiming
  flow can be only reverted by killing the whole enclave.
* Fixed SGX_ATTR_RESERVED_MASK. Bit 7 was marked as reserved while in fact
  it should have been bit 6 (Table 37-3 in the SDM).
* Return -EPERM from SGX_IOC_ENCLAVE_INIT when ENCLS[EINIT] returns an SGX
  error code.

v22:
* Refined bunch commit messages and added associated SDM references as
  many of them were too exhausting and some outdated.
* Alignment checks have been removed from mmap() because it does not define
  the ELRANGE. VMAs only act as windows to the enclave. The semantics
  compare somewhat how mmap() works with regular files.
* We now require user space addresses given to SGX_IOC_ENCLAVE_ADD_PAGE to be
  page aligned so that we can pass the page directly to EADD and do not have
  to do an extra copy. This was made effectively possible by removing the
  worker thread for adding pages.
* The selftest build files have been refined throughout of various glitches
  and work properly in a cross compilation environment such as BuildRoot.
  In addition, libcalls fail the build with an assertion in the linker
  script, if they end up to the enclave binary.
* CONFIG_INTEL_SGX_DRIVER has been removed because you cannot use SGX core
  for anything without having the driver. This could change when KVM support
  is added.
* We require zero permissions in SECINFO for TCS pages because the CPU
  overwrites SECINFO flags with zero permissions and measures the page
  only after that. Allowing to pass TCS with non-zero permissions would
  cause mismatching measurement between the one provided in SIGSTRUCT and
  the one computed by the CPU.
* Obviously lots of small fixes and clean ups (does make sense to
  document them all).

v21:
* Check on mmap() that the VMA does cover an area that does not have
  enclave pages. Only mapping with PROT_NONE can do that to reserve
  initial address space for an enclave.
* Check om mmap() and mprotect() that the VMA permissions do not
  surpass the enclave permissions.
* Remove two refcounts from vma_close(): mm_list and encl->refcount.
  Enclave refcount is only need for swapper/enclave sync and we can
  remove mm_list refcount by destroying mm_struct when the process
  is closed. By not having vm_close() the Linux MM can merge VMAs.
* Do not naturally align MAP_FIXED address.
* Numerous small fixes and clean ups.
* Use SRCU for synchronizing the list of mm_struct's.
* Move to stack based call convention in the vDSO.

v20:
* Fine-tune Kconfig messages and spacing and remove MMU_NOTIFIER
  dependency as MMU notifiers are no longer used in the driver.
* Use mm_users instead of mm_count as refcount for mm_struct as mm_count
  only protects from deleting mm_struct, not removing its contents.
* Sanitize EPC when the reclaimer thread starts by doing EREMOVE for all
  of them. They could be in initialized state when the kernel starts
  because it might be spawned by kexec().
* Documentation overhaul.
* Use a device /dev/sgx/provision for delivering the provision token
  instead of securityfs.
* Create a reference to the enclave when already when opening
  /dev/sgx/enclave.  The file is then associated with this enclave only.
  mmap() can be done at free at any point and always get a reference to
  the enclave. To summarize the file now represents the enclave.

v19:
* Took 3-4 months but in some sense this was more like a rewrite of most
  of the corners of the source code. If I've forgotten to deal with some
  feedback, please don't shout me. Make a remark and I will fix it for
  the next version. Hopefully there won't be this big turnovers anymore.
* Validate SECS attributes properly against CPUID given attributes and
  against allowed attributes. SECS attributes are the ones that are
  enforced whereas SIGSTRUCT attributes tell what is required to run
  the enclave.
* Add KSS (Key Sharing Support) to the enclave attributes.
* Deny MAP_PRIVATE as an enclave is always a shared memory entity.
* Revert back to shmem backing storage so that it can be easily shared
  by multiple processes.
* Split the recognization of an ENCLS leaf failure by using three
  functions to detect it: encsl_faulted(), encls_returned_code() and
  sgx_failed(). encls_failed() is only caused by a spurious expections that
  should never happen. Thus, it is not defined as an inline function in
  order to easily insert a kprobe to it.
* Move low-level enclave management routines, page fault handler and page
  reclaiming routines from driver to the core. These cannot be separated
  from each other as they are heavily interdependent. The rationale is that
  the core does not call any code from the driver.
* Allow the driver to be compiled as a module now that it no code is using
  its routines and it only uses exported symbols. Now the driver is
  essentially just a thin ioctl layer.
* Reworked the driver to maintain a list of mm_struct's. The VMA callbacks
  add new entries to this list as the process is forked. Each entry has
  its own refcount because they have a different life-cycle as the enclave
  does. In effect @tgid and @mm have been removed from struct sgx_encl
  and we allow forking by removing VM_DONTCOPY from vm flags.
* Generate a cpu mask in the reclaimer from the cpu mask's of all
  mm_struct's. This will kick out the hardware threads out of the enclave
  from multiple processes. It is not a local variable because it would
  eat too much of the stack space but instead a field in struct
  sgx_encl.
* Allow forking i.e. remove VM_DONTCOPY. I did not change the API
  because the old API scaled to the workload that Andy described. The
  codebase is now mostly API independent i.e. changing the API is a
  small task. For me the proper trigger to chanage it is a as concrete
  as possible workload that cannot be fulfilled. I hope you understand
  my thinking here. I don't want to change anything w/o proper basis
  but I'm ready to change anything if there is a proper basis. I do
  not have any kind of attachment to any particular type of API.
* Add Sean's vDSO ENCLS(EENTER) patches and update selftest to use the
  new vDSO.

v18:
* Update the ioctl-number.txt.
* Move the driver under arch/x86.
* Add SGX features (SGX, SGX1, SGX2) to the disabled-features.h.
* Rename the selftest as test_sgx (previously sgx-selftest).
* In order to enable process accounting, swap EPC pages and PCMD's to a VMA
  instead of shmem.
* Allow only to initialize and run enclaves with a subset of
  {DEBUG, MODE64BIT} set.
* Add SGX_IOC_ENCLAVE_SET_ATTRIBUTE to allow an enclave to have privileged
  attributes e.g. PROVISIONKEY.

v17:
* Add a simple selftest.
* Fix a null pointer dereference to section->pages when its
  allocation fails.
* Add Sean's description of the exception handling to the documentation.

v16:
* Fixed SOB's in the commits that were a bit corrupted in v15.
* Implemented exceptio handling properly to detect_sgx().
* Use GENMASK() to define SGX_CPUID_SUB_LEAF_TYPE_MASK.
* Updated the documentation to use rst definition lists.
* Added the missing Documentation/x86/index.rst, which has a link to
  intel_sgx.rst. Now the SGX and uapi documentation is properly generated
  with 'make htmldocs'.
* While enumerating EPC sections, if an undefined section is found, fail
  the driver initialization instead of continuing the initialization.
* Issue a warning if there are more than %SGX_MAX_EPC_SECTIONS.
* Remove copyright notice from arch/x86/include/asm/sgx.h.
* Migrated from ioremap_cache() to memremap().

v15:
* Split into more digestable size patches.
* Lots of small fixes and clean ups.
* Signal a "plain" SIGSEGV on an EPCM violation.

v14:
* Change the comment about X86_FEATURE_SGX_LC from “SGX launch
  configuration” to “SGX launch control”.
* Move the SGX-related CPU feature flags as part of the Linux defined
  virtual leaf 8.
* Add SGX_ prefix to the constants defining the ENCLS leaf functions.
* Use GENMASK*() and BIT*() in sgx_arch.h instead of raw hex numbers.
* Refine the long description for CONFIG_INTEL_SGX_CORE.
* Do not use pr_*_ratelimited()  in the driver. The use of the rate limited
  versions is legacy cruft from the prototyping phase.
* Detect sleep with SGX_INVALID_EINIT_TOKEN instead of counting power
  cycles.
* Manually prefix with “sgx:” in the core SGX code instead of redefining
  pr_fmt.
* Report if IA32_SGXLEPUBKEYHASHx MSRs are not writable in the driver
  instead of core because it is a driver requirement.
* Change prompt to bool in the entry for CONFIG_INTEL_SGX_CORE because the
  default is ‘n’.
* Rename struct sgx_epc_bank as struct sgx_epc_section in order to match
  the SDM.
* Allocate struct sgx_epc_page instances one at a time.
* Use “__iomem void *” pointers for the mapped EPC memory consistently.
* Retry once on SGX_INVALID_TOKEN in sgx_einit() instead of counting power
  cycles.
* Call enclave swapping operations directly from the driver instead of
  calling them .indirectly through struct sgx_epc_page_ops because indirect
  calls are not required yet as the patch set does not contain the KVM
  support.
* Added special signal SEGV_SGXERR to notify about SGX EPCM violation
  errors.

v13:
* Always use SGX_CPUID constant instead of a hardcoded value.
* Simplified and documented the macros and functions for ENCLS leaves.
* Enable sgx_free_page() to free active enclave pages on demand
  in order to allow sgx_invalidate() to delete enclave pages.
  It no longer performs EREMOVE if a page is in the process of
  being reclaimed.
* Use PM notifier per enclave so that we don't have to traverse
  the global list of active EPC pages to find enclaves.
* Removed unused SGX_LE_ROLLBACK constant from uapi/asm/sgx.h
* Always use ioremap() to map EPC banks as we only support 64-bit kernel.
* Invalidate IA32_SGXLEPUBKEYHASH cache used by sgx_einit() when going
  to sleep.

v12:
* Split to more narrow scoped commits in order to ease the review process and
  use co-developed-by tag for co-authors of commits instead of listing them in
  the source files.
* Removed cruft EXPORT_SYMBOL() declarations and converted to static variables.
* Removed in-kernel LE i.e. this version of the SGX software stack only
  supports unlocked IA32_SGXLEPUBKEYHASHx MSRs.
* Refined documentation on launching enclaves, swapping and enclave
  construction.
* Refined sgx_arch.h to include alignment information for every struct that
  requires it and removed structs that are not needed without an LE.
* Got rid of SGX_CPUID.
* SGX detection now prints log messages about firmware configuration issues.

v11:
* Polished ENCLS wrappers with refined exception handling.
* ksgxswapd was not stopped (regression in v5) in
  sgx_page_cache_teardown(), which causes a leaked kthread after driver
  deinitialization.
* Shutdown sgx_le_proxy when going to suspend because its EPC pages will be
  invalidated when resuming, which will cause it not function properly
  anymore.
* Set EINITTOKEN.VALID to zero for a token that is passed when
  SGXLEPUBKEYHASH matches MRSIGNER as alloc_page() does not give a zero
  page.
* Fixed the check in sgx_edbgrd() for a TCS page. Allowed to read offsets
  around the flags field, which causes a #GP. Only flags read is readable.
* On read access memcpy() call inside sgx_vma_access() had src and dest
  parameters in wrong order.
* The build issue with CONFIG_KASAN is now fixed. Added undefined symbols
  to LE even if “KASAN_SANITIZE := false” was set in the makefile.
* Fixed a regression in the #PF handler. If a page has
  SGX_ENCL_PAGE_RESERVED flag the #PF handler should unconditionally fail.
  It did not, which caused weird races when trying to change other parts of
  swapping code.
* EPC management has been refactored to a flat LRU cache and moved to
  arch/x86. The swapper thread reads a cluster of EPC pages and swaps all
  of them. It can now swap from multiple enclaves in the same round.
* For the sake of consistency with SGX_IOC_ENCLAVE_ADD_PAGE, return -EINVAL
  when an enclave is already initialized or dead instead of zero.

v10:
* Cleaned up anon inode based IPC between the ring-0 and ring-3 parts
  of the driver.
* Unset the reserved flag from an enclave page if EDBGRD/WR fails
  (regression in v6).
* Close the anon inode when LE is stopped (regression in v9).
* Update the documentation with a more detailed description of SGX.

v9:
* Replaced kernel-LE IPC based on pipes with an anonymous inode.
  The driver does not require anymore new exports.

v8:
* Check that public key MSRs match the LE public key hash in the
  driver initialization when the MSRs are read-only.
* Fix the race in VA slot allocation by checking the fullness
  immediately after succeesful allocation.
* Fix the race in hash mrsigner calculation between the launch
  enclave and user enclaves by having a separate lock for hash
  calculation.

v7:
* Fixed offset calculation in sgx_edbgr/wr(). Address was masked with PAGE_MASK
  when it should have been masked with ~PAGE_MASK.
* Fixed a memory leak in sgx_ioc_enclave_create().
* Simplified swapping code by using a pointer array for a cluster
  instead of a linked list.
* Squeezed struct sgx_encl_page to 32 bytes.
* Fixed deferencing of an RSA key on OpenSSL 1.1.0.
* Modified TC's CMAC to use kernel AES-NI. Restructured the code
  a bit in order to better align with kernel conventions.

v6:
* Fixed semaphore underrun when accessing /dev/sgx from the launch enclave.
* In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/.
* Removed virtualization chapter from the documentation.
* Changed the default filename for the signing key as signing_key.pem.
* Reworked EPC management in a way that instead of a linked list of
  struct sgx_epc_page instances there is an array of integers that
  encodes address and bank of an EPC page (the same data as 'pa' field
  earlier). The locking has been moved to the EPC bank level instead
  of a global lock.
* Relaxed locking requirements for EPC management. EPC pages can be
  released back to the EPC bank concurrently.
* Cleaned up ptrace() code.
* Refined commit messages for new architectural constants.
* Sorted includes in every source file.
* Sorted local variable declarations according to the line length in
  every function.
* Style fixes based on Darren's comments to sgx_le.c.

v5:
* Described IPC between the Launch Enclave and kernel in the commit messages.
* Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier
  versions except those that exist in the imported TinyCrypt code.
* Fixed spelling mistakes in the documentation.
* Forgot to check the return value of sgx_drv_subsys_init().
* Encapsulated properly page cache init and teardown.
* Collect epc pages to a temp list in sgx_add_epc_bank
* Removed SGX_ENCLAVE_INIT_ARCH constant.

v4:
* Tied life-cycle of the sgx_le_proxy process to /dev/sgx.
* Removed __exit annotation from sgx_drv_subsys_exit().
* Fixed a leak of a backing page in sgx_process_add_page_req() in the
  case when vm_insert_pfn() fails.
* Removed unused symbol exports for sgx_page_cache.c.
* Updated sgx_alloc_page() to require encl parameter and documented the
  behavior (Sean Christopherson).
* Refactored a more lean API for sgx_encl_find() and documented the behavior.
* Moved #PF handler to sgx_fault.c.
* Replaced subsys_system_register() with plain bus_register().
* Retry EINIT 2nd time only if MSRs are not locked.

v3:
* Check that FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_SGX_ENABLE are set.
* Return -ERESTARTSYS in __sgx_encl_add_page() when sgx_alloc_page() fails.
* Use unused bits in epc_page->pa to store the bank number.
* Removed #ifdef for WQ_NONREENTRANT.
* If mmu_notifier_register() fails with -EINTR, return -ERESTARTSYS.
* Added --remove-section=.got.plt to objcopy flags in order to prevent a
  dummy .got.plt, which will cause an inconsistent size for the LE.
* Documented sgx_encl_* functions.
* Added remark about AES implementation used inside the LE.
* Removed redundant sgx_sys_exit() from le/main.c.
* Fixed struct sgx_secinfo alignment from 128 to 64 bytes.
* Validate miscselect in sgx_encl_create().
* Fixed SSA frame size calculation to take the misc region into account.
* Implemented consistent exception handling to __encls() and __encls_ret().
* Implemented a proper device model in order to allow sysfs attributes
  and in-kernel API.
* Cleaned up various "find enclave" implementations to the unified
  sgx_encl_find().
* Validate that vm_pgoff is zero.
* Discard backing pages with shmem_truncate_range() after EADD.
* Added missing EEXTEND operations to LE signing and launch.
* Fixed SSA size for GPRS region from 168 to 184 bytes.
* Fixed the checks for TCS flags. Now DBGOPTIN is allowed.
* Check that TCS addresses are in ELRANGE and not just page aligned.
* Require kernel to be compiled with X64_64 and CPU_SUP_INTEL.
* Fixed an incorrect value for SGX_ATTR_DEBUG from 0x01 to 0x02.

v2:
* get_rand_uint32() changed the value of the pointer instead of value
  where it is pointing at.
* Launch enclave incorrectly used sigstruct attributes-field instead of
  enclave attributes-field.
* Removed unused struct sgx_add_page_req from sgx_ioctl.c
* Removed unused sgx_has_sgx2.
* Updated arch/x86/include/asm/sgx.h so that it provides stub
  implementations when sgx in not enabled.
* Removed cruft rdmsr-calls from sgx_set_pubkeyhash_msrs().
* return -ENOMEM in sgx_alloc_page() when VA pages consume too much space
* removed unused global sgx_nr_pids
* moved sgx_encl_release to sgx_encl.c
* return -ERESTARTSYS instead of -EINTR in sgx_encl_init()

Jarkko Sakkinen (14):
  x86/sgx: Add SGX microarchitectural data structures
  x86/sgx: Add wrappers for ENCLS leaf functions
  x86/cpu/intel: Add nosgx kernel parameter
  x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page()
  x86/sgx: Add SGX enclave driver
  x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES
  x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  x86/sgx: Enable provisioning for remote attestation
  x86/sgx: Add a page reclaimer
  x86/sgx: ptrace() support for the SGX driver
  selftests/x86: Add a selftest for SGX
  docs: x86/sgx: Document SGX micro architecture and kernel internals
  x86/sgx: Update MAINTAINERS

Sean Christopherson (10):
  x86/cpufeatures: x86/msr: Add Intel SGX hardware bits
  x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits
  x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
  x86/cpu/intel: Detect SGX support
  x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections
  mm: Add vm_ops->mprotect()
  x86/vdso: Add support for exception fixup in vDSO functions
  x86/fault: Add helper function to sanitize error code
  x86/traps: Attempt to fixup exceptions in vDSO before signaling
  x86/vdso: Implement a vDSO for Intel SGX enclave call

 .../admin-guide/kernel-parameters.txt         |   2 +
 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 Documentation/x86/index.rst                   |   1 +
 Documentation/x86/sgx.rst                     | 200 +++++
 MAINTAINERS                                   |  11 +
 arch/x86/Kconfig                              |  17 +
 arch/x86/entry/vdso/Makefile                  |   8 +-
 arch/x86/entry/vdso/extable.c                 |  46 +
 arch/x86/entry/vdso/extable.h                 |  29 +
 arch/x86/entry/vdso/vdso-layout.lds.S         |   9 +-
 arch/x86/entry/vdso/vdso.lds.S                |   1 +
 arch/x86/entry/vdso/vdso2c.h                  |  50 +-
 arch/x86/entry/vdso/vsgx_enter_enclave.S      | 157 ++++
 arch/x86/include/asm/cpufeature.h             |   5 +-
 arch/x86/include/asm/cpufeatures.h            |   8 +-
 arch/x86/include/asm/disabled-features.h      |  18 +-
 arch/x86/include/asm/enclu.h                  |   8 +
 arch/x86/include/asm/msr-index.h              |   8 +
 arch/x86/include/asm/required-features.h      |   2 +-
 arch/x86/include/asm/traps.h                  |  14 +-
 arch/x86/include/asm/vdso.h                   |   5 +
 arch/x86/include/uapi/asm/sgx.h               | 203 +++++
 arch/x86/kernel/cpu/Makefile                  |   1 +
 arch/x86/kernel/cpu/common.c                  |   4 +
 arch/x86/kernel/cpu/feat_ctl.c                |  41 +-
 arch/x86/kernel/cpu/sgx/Makefile              |   5 +
 arch/x86/kernel/cpu/sgx/arch.h                | 341 ++++++++
 arch/x86/kernel/cpu/sgx/driver.c              | 204 +++++
 arch/x86/kernel/cpu/sgx/driver.h              |  32 +
 arch/x86/kernel/cpu/sgx/encl.c                | 754 ++++++++++++++++
 arch/x86/kernel/cpu/sgx/encl.h                | 128 +++
 arch/x86/kernel/cpu/sgx/encls.h               | 238 +++++
 arch/x86/kernel/cpu/sgx/ioctl.c               | 823 ++++++++++++++++++
 arch/x86/kernel/cpu/sgx/main.c                | 753 ++++++++++++++++
 arch/x86/kernel/cpu/sgx/sgx.h                 |  65 ++
 arch/x86/kernel/traps.c                       |  19 +-
 arch/x86/mm/fault.c                           |  45 +-
 include/linux/mm.h                            |   3 +
 mm/mprotect.c                                 |   5 +-
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/sgx/.gitignore        |   2 +
 tools/testing/selftests/sgx/Makefile          |  53 ++
 tools/testing/selftests/sgx/call.S            |  44 +
 tools/testing/selftests/sgx/defines.h         |  21 +
 tools/testing/selftests/sgx/load.c            | 277 ++++++
 tools/testing/selftests/sgx/main.c            | 232 +++++
 tools/testing/selftests/sgx/main.h            |  38 +
 tools/testing/selftests/sgx/sigstruct.c       | 395 +++++++++
 tools/testing/selftests/sgx/test_encl.c       |  20 +
 tools/testing/selftests/sgx/test_encl.lds     |  40 +
 .../selftests/sgx/test_encl_bootstrap.S       |  89 ++
 51 files changed, 5446 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/x86/sgx.rst
 create mode 100644 arch/x86/entry/vdso/extable.c
 create mode 100644 arch/x86/entry/vdso/extable.h
 create mode 100644 arch/x86/entry/vdso/vsgx_enter_enclave.S
 create mode 100644 arch/x86/include/asm/enclu.h
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 arch/x86/kernel/cpu/sgx/Makefile
 create mode 100644 arch/x86/kernel/cpu/sgx/arch.h
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.c
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.h
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.h
 create mode 100644 arch/x86/kernel/cpu/sgx/encls.h
 create mode 100644 arch/x86/kernel/cpu/sgx/ioctl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/main.c
 create mode 100644 arch/x86/kernel/cpu/sgx/sgx.h
 create mode 100644 tools/testing/selftests/sgx/.gitignore
 create mode 100644 tools/testing/selftests/sgx/Makefile
 create mode 100644 tools/testing/selftests/sgx/call.S
 create mode 100644 tools/testing/selftests/sgx/defines.h
 create mode 100644 tools/testing/selftests/sgx/load.c
 create mode 100644 tools/testing/selftests/sgx/main.c
 create mode 100644 tools/testing/selftests/sgx/main.h
 create mode 100644 tools/testing/selftests/sgx/sigstruct.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.lds
 create mode 100644 tools/testing/selftests/sgx/test_encl_bootstrap.S

-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen
                   ` (22 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Borislav Petkov,
	Jethro Beekman, Darren Kenny, Jarkko Sakkinen, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Add X86_FEATURE_SGX from CPUID.(EAX=7, ECX=1), which informs whether the
CPU has SGX.

Add X86_FEATURE_SGX1 and X86_FEATURE_SGX2 from CPUID.(EAX=12H, ECX=0),
which describe the level of SGX support available [1].

Add IA32_FEATURE_CONTROL.SGX_ENABLE. BIOS can use this bit to opt-in SGX
before locking the feature control MSR [2].

[1] Intel SDM: 36.7.2 Intel® SGX Resource Enumeration Leaves
[2] Intel SDM: 36.7.1 Intel® SGX Opt-In Configuration

Reviewed-by: Borislav Petkov <bp@alien8.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/asm/cpufeature.h        |  5 +++--
 arch/x86/include/asm/cpufeatures.h       |  7 ++++++-
 arch/x86/include/asm/disabled-features.h | 18 +++++++++++++++---
 arch/x86/include/asm/msr-index.h         |  1 +
 arch/x86/include/asm/required-features.h |  2 +-
 arch/x86/kernel/cpu/common.c             |  4 ++++
 6 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 59bf91c57aa8..efbdba5170a3 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -30,6 +30,7 @@ enum cpuid_leafs
 	CPUID_7_ECX,
 	CPUID_8000_0007_EBX,
 	CPUID_7_EDX,
+	CPUID_12_EAX,
 };
 
 #ifdef CONFIG_X86_FEATURE_NAMES
@@ -89,7 +90,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 	   CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 17, feature_bit) ||	\
 	   CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 18, feature_bit) ||	\
 	   REQUIRED_MASK_CHECK					  ||	\
-	   BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+	   BUILD_BUG_ON_ZERO(NCAPINTS != 20))
 
 #define DISABLED_MASK_BIT_SET(feature_bit)				\
 	 ( CHECK_BIT_IN_MASK_WORD(DISABLED_MASK,  0, feature_bit) ||	\
@@ -112,7 +113,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 	   CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 17, feature_bit) ||	\
 	   CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 18, feature_bit) ||	\
 	   DISABLED_MASK_CHECK					  ||	\
-	   BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+	   BUILD_BUG_ON_ZERO(NCAPINTS != 20))
 
 #define cpu_has(c, bit)							\
 	(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 :	\
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 2901d5df4366..159b635159c0 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -13,7 +13,7 @@
 /*
  * Defines x86 CPU feature bits
  */
-#define NCAPINTS			19	   /* N 32-bit words worth of info */
+#define NCAPINTS			20	   /* N 32-bit words worth of info */
 #define NBUGINTS			1	   /* N 32-bit bug flags */
 
 /*
@@ -240,6 +240,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (EBX), word 9 */
 #define X86_FEATURE_FSGSBASE		( 9*32+ 0) /* RDFSBASE, WRFSBASE, RDGSBASE, WRGSBASE instructions*/
 #define X86_FEATURE_TSC_ADJUST		( 9*32+ 1) /* TSC adjustment MSR 0x3B */
+#define X86_FEATURE_SGX			( 9*32+ 2) /* Software Guard Extensions */
 #define X86_FEATURE_BMI1		( 9*32+ 3) /* 1st group bit manipulation extensions */
 #define X86_FEATURE_HLE			( 9*32+ 4) /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2		( 9*32+ 5) /* AVX2 instructions */
@@ -377,6 +378,10 @@
 #define X86_FEATURE_CORE_CAPABILITIES	(18*32+30) /* "" IA32_CORE_CAPABILITIES MSR */
 #define X86_FEATURE_SPEC_CTRL_SSBD	(18*32+31) /* "" Speculative Store Bypass Disable */
 
+/* Intel-defined SGX features, CPUID level 0x00000012:0 (EAX), word 19 */
+#define X86_FEATURE_SGX1		(19*32+ 0) /* SGX1 leaf functions */
+#define X86_FEATURE_SGX2		(19*32+ 1) /* SGX2 leaf functions */
+
 /*
  * BUG word(s)
  */
diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
index 4ea8584682f9..dbe534d5153f 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -28,13 +28,18 @@
 # define DISABLE_CYRIX_ARR	(1<<(X86_FEATURE_CYRIX_ARR & 31))
 # define DISABLE_CENTAUR_MCR	(1<<(X86_FEATURE_CENTAUR_MCR & 31))
 # define DISABLE_PCID		0
+# define DISABLE_SGX1		0
+# define DISABLE_SGX2		0
 #else
 # define DISABLE_VME		0
 # define DISABLE_K6_MTRR	0
 # define DISABLE_CYRIX_ARR	0
 # define DISABLE_CENTAUR_MCR	0
 # define DISABLE_PCID		(1<<(X86_FEATURE_PCID & 31))
-#endif /* CONFIG_X86_64 */
+# define DISABLE_SGX1		(1<<(X86_FEATURE_SGX1 & 31))
+# define DISABLE_SGX2		(1<<(X86_FEATURE_SGX2 & 31))
+ #endif /* CONFIG_X86_64 */
+
 
 #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
 # define DISABLE_PKU		0
@@ -56,6 +61,12 @@
 # define DISABLE_PTI		(1 << (X86_FEATURE_PTI & 31))
 #endif
 
+#ifdef CONFIG_INTEL_SGX
+# define DISABLE_SGX	0
+#else
+# define DISABLE_SGX	(1 << (X86_FEATURE_SGX & 31))
+#endif
+
 /*
  * Make sure to add features to the correct mask
  */
@@ -68,7 +79,7 @@
 #define DISABLED_MASK6	0
 #define DISABLED_MASK7	(DISABLE_PTI)
 #define DISABLED_MASK8	0
-#define DISABLED_MASK9	(DISABLE_SMAP)
+#define DISABLED_MASK9	(DISABLE_SMAP|DISABLE_SGX)
 #define DISABLED_MASK10	0
 #define DISABLED_MASK11	0
 #define DISABLED_MASK12	0
@@ -78,6 +89,7 @@
 #define DISABLED_MASK16	(DISABLE_PKU|DISABLE_OSPKE|DISABLE_LA57|DISABLE_UMIP)
 #define DISABLED_MASK17	0
 #define DISABLED_MASK18	0
-#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 19)
+#define DISABLED_MASK19	(DISABLE_SGX1|DISABLE_SGX2)
+#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 20)
 
 #endif /* _ASM_X86_DISABLED_FEATURES_H */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 2859ee4f39a8..c0b04f020162 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -602,6 +602,7 @@
 #define FEAT_CTL_LOCKED				BIT(0)
 #define FEAT_CTL_VMX_ENABLED_INSIDE_SMX		BIT(1)
 #define FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX	BIT(2)
+#define FEAT_CTL_SGX_ENABLED			BIT(18)
 #define FEAT_CTL_LMCE_ENABLED			BIT(20)
 
 #define MSR_IA32_TSC_ADJUST             0x0000003b
diff --git a/arch/x86/include/asm/required-features.h b/arch/x86/include/asm/required-features.h
index 6847d85400a8..039e58be2fe6 100644
--- a/arch/x86/include/asm/required-features.h
+++ b/arch/x86/include/asm/required-features.h
@@ -101,6 +101,6 @@
 #define REQUIRED_MASK16	0
 #define REQUIRED_MASK17	0
 #define REQUIRED_MASK18	0
-#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 19)
+#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 20)
 
 #endif /* _ASM_X86_REQUIRED_FEATURES_H */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c5d6f17d9b9d..ccd9a11d5d1a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -931,6 +931,10 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 		c->x86_capability[CPUID_D_1_EAX] = eax;
 	}
 
+	/* Additional Intel-defined SGX flags: level 0x00000012 */
+	if (c->cpuid_level >= 0x00000012)
+		c->x86_capability[CPUID_12_EAX] = cpuid_eax(0x00000012);
+
 	/* AMD-defined flags: level 0x80000001 */
 	eax = cpuid_eax(0x80000000);
 	c->extended_cpuid_level = eax;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
                   ` (21 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Borislav Petkov,
	Jethro Beekman, Darren Kenny, Jarkko Sakkinen, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Add X86_FEATURE_SGX_LC, which informs whether or not the CPU supports SGX
Launch Control.

Add MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}, which when combined contain a
SHA256 hash of a 3072-bit RSA public key. SGX backed software packages, so
called enclaves, are always signed. All enclaves signed with the public key
are unconditionally allowed to initialize. [1]

Add FEAT_CTL_SGX_LC_ENABLED, which informs whether the aformentioned MSRs
are writable or not. If the bit is off, the public key MSRs are read-only
for the OS.

If the MSRs are read-only, the platform must provide a launch enclave (LE).
LE can create cryptographic tokens for other enclaves that they can pass
together with their signature to the ENCLS(EINIT) opcode, which is used
to initialize enclaves.

Linux is unlikely to support the locked configuration because it takes away
the control of the launch decisions from the kernel.

[1] Intel SDM: 38.1.4 Intel SGX Launch Control Configuration

Reviewed-by: Borislav Petkov <bp@alien8.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/include/asm/msr-index.h   | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 159b635159c0..398e4f19c3d7 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -354,6 +354,7 @@
 #define X86_FEATURE_CLDEMOTE		(16*32+25) /* CLDEMOTE instruction */
 #define X86_FEATURE_MOVDIRI		(16*32+27) /* MOVDIRI instruction */
 #define X86_FEATURE_MOVDIR64B		(16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_SGX_LC		(16*32+30) /* Software Guard Extensions Launch Control */
 
 /* AMD-defined CPU features, CPUID level 0x80000007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV	(17*32+ 0) /* MCA overflow recovery support */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c0b04f020162..e574b4bb5aad 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -602,6 +602,7 @@
 #define FEAT_CTL_LOCKED				BIT(0)
 #define FEAT_CTL_VMX_ENABLED_INSIDE_SMX		BIT(1)
 #define FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX	BIT(2)
+#define FEAT_CTL_SGX_LC_ENABLED			BIT(17)
 #define FEAT_CTL_SGX_ENABLED			BIT(18)
 #define FEAT_CTL_LMCE_ENABLED			BIT(20)
 
@@ -622,6 +623,12 @@
 #define MSR_IA32_UCODE_WRITE		0x00000079
 #define MSR_IA32_UCODE_REV		0x0000008b
 
+/* Intel SGX Launch Enclave Public Key Hash MSRs */
+#define MSR_IA32_SGXLEPUBKEYHASH0	0x0000008C
+#define MSR_IA32_SGXLEPUBKEYHASH1	0x0000008D
+#define MSR_IA32_SGXLEPUBKEYHASH2	0x0000008E
+#define MSR_IA32_SGXLEPUBKEYHASH3	0x0000008F
+
 #define MSR_IA32_SMM_MONITOR_CTL	0x0000009b
 #define MSR_IA32_SMBASE			0x0000009e
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-16 11:44   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 04/24] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
                   ` (20 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Jethro Beekman, Darren Kenny,
	Borislav Petkov, Jarkko Sakkinen, akpm, andriy.shevchenko,
	asapek, bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Include SGX bit to the PF error codes and throw SIGSEGV with PF_SGX when
a #PF with SGX set happens.

CPU throws a #PF with the SGX set in the event of Enclave Page Cache Map
(EPCM) conflict. The EPCM is a CPU-internal table, which describes the
properties for a enclave page. Enclaves are measured and signed software
entities, which SGX hosts. [1]

Although the primary purpose of the EPCM conflict checks  is to prevent
malicious accesses to an enclave, an illegit access can happen also for
legit reasons.

All SGX reserved memory, including EPCM is encrypted with a transient key
that does not survive from the power transition. Throwing a SIGSEGV allows
user space software to react when this happens (e.g. recreate the enclave,
which was invalidated).

[1] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM)

Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/asm/traps.h | 14 ++++++++------
 arch/x86/mm/fault.c          | 13 +++++++++++++
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 714b1a30e7b0..4446f95ad997 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -44,12 +44,13 @@ void __noreturn handle_stack_overflow(const char *message,
 /*
  * Page fault error code bits:
  *
- *   bit 0 ==	 0: no page found	1: protection fault
- *   bit 1 ==	 0: read access		1: write access
- *   bit 2 ==	 0: kernel-mode access	1: user-mode access
- *   bit 3 ==				1: use of reserved bit detected
- *   bit 4 ==				1: fault was an instruction fetch
- *   bit 5 ==				1: protection keys block access
+ *   bit 0  ==	 0: no page found	1: protection fault
+ *   bit 1  ==	 0: read access		1: write access
+ *   bit 2  ==	 0: kernel-mode access	1: user-mode access
+ *   bit 3  ==				1: use of reserved bit detected
+ *   bit 4  ==				1: fault was an instruction fetch
+ *   bit 5  ==				1: protection keys block access
+ *   bit 15 ==				1: inside SGX enclave
  */
 enum x86_pf_error_code {
 	X86_PF_PROT	=		1 << 0,
@@ -58,5 +59,6 @@ enum x86_pf_error_code {
 	X86_PF_RSVD	=		1 << 3,
 	X86_PF_INSTR	=		1 << 4,
 	X86_PF_PK	=		1 << 5,
+	X86_PF_SGX	=		1 << 15,
 };
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 35f1498e9832..1a7cc6d3281a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1054,6 +1054,19 @@ access_error(unsigned long error_code, struct vm_area_struct *vma)
 	if (error_code & X86_PF_PK)
 		return 1;
 
+	/*
+	 * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
+	 * access is allowed by the PTE but not the EPCM. This usually happens
+	 * when the EPCM is yanked out from under us, e.g. by hardware after a
+	 * suspend/resume cycle. In any case, software, i.e. the kernel, can't
+	 * fix the source of the fault as the EPCM can't be directly modified by
+	 * software. Handle the fault as an access error in order to signal
+	 * userspace so that userspace can rebuild their enclave(s), even though
+	 * userspace may not have actually violated access permissions.
+	 */
+	if (unlikely(error_code & X86_PF_SGX))
+		return 1;
+
 	/*
 	 * Make sure to check the VMA so that we do not perform
 	 * faults just to hit a X86_PF_PK as soon as we fill in a
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 04/24] x86/sgx: Add SGX microarchitectural data structures
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (2 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 05/24] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
                   ` (19 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Darren Kenny,
	akpm, andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

Define the SGX microarchitectural data structures used by various SGX
opcodes. This is not an exhaustive representation of all SGX data
structures but only those needed by the kernel.

The data structures are described in:

  Intel SDM: 37.6 INTEL® SGX DATA STRUCTURES OVERVIEW

Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/arch.h | 341 +++++++++++++++++++++++++++++++++
 1 file changed, 341 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/arch.h

diff --git a/arch/x86/kernel/cpu/sgx/arch.h b/arch/x86/kernel/cpu/sgx/arch.h
new file mode 100644
index 000000000000..ccecc39728dc
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/arch.h
@@ -0,0 +1,341 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+ * Copyright(c) 2016-18 Intel Corporation.
+ *
+ * Contains data structures defined by the SGX architecture.  Data structures
+ * defined by the Linux software stack should not be placed here.
+ */
+#ifndef _ASM_X86_SGX_ARCH_H
+#define _ASM_X86_SGX_ARCH_H
+
+#include <linux/bits.h>
+#include <linux/types.h>
+
+#define SGX_CPUID				0x12
+#define SGX_CPUID_FIRST_VARIABLE_SUB_LEAF	2
+
+/**
+ * enum sgx_return_code - The return code type for ENCLS, ENCLU and ENCLV
+ * %SGX_NOT_TRACKED:		Previous ETRACK's shootdown sequence has not
+ *				been completed yet.
+ * %SGX_INVALID_EINITTOKEN:	EINITTOKEN is invalid and enclave signer's
+ *				public key does not match IA32_SGXLEPUBKEYHASH.
+ * %SGX_UNMASKED_EVENT:		An unmasked event, e.g. INTR, was received
+ */
+enum sgx_return_code {
+	SGX_NOT_TRACKED			= 11,
+	SGX_INVALID_EINITTOKEN		= 16,
+	SGX_UNMASKED_EVENT		= 128,
+};
+
+/**
+ * enum sgx_sub_leaf_types - SGX CPUID variable sub-leaf types
+ * %SGX_CPUID_SUB_LEAF_INVALID:		Indicates this sub-leaf is invalid.
+ * %SGX_CPUID_SUB_LEAF_EPC_SECTION:	Sub-leaf enumerates an EPC section.
+ */
+enum sgx_sub_leaf_types {
+	SGX_CPUID_SUB_LEAF_INVALID	= 0x0,
+	SGX_CPUID_SUB_LEAF_EPC_SECTION	= 0x1,
+};
+
+#define SGX_CPUID_SUB_LEAF_TYPE_MASK	GENMASK(3, 0)
+
+#define SGX_MODULUS_SIZE 384
+
+/**
+ * enum sgx_miscselect - additional information to an SSA frame
+ * %SGX_MISC_EXINFO:	Report #PF or #GP to the SSA frame.
+ *
+ * Save State Area (SSA) is a stack inside the enclave used to store processor
+ * state when an exception or interrupt occurs. This enum defines additional
+ * information stored to an SSA frame.
+ */
+enum sgx_miscselect {
+	SGX_MISC_EXINFO		= BIT(0),
+};
+
+#define SGX_MISC_RESERVED_MASK	GENMASK_ULL(63, 1)
+
+#define SGX_SSA_GPRS_SIZE		184
+#define SGX_SSA_MISC_EXINFO_SIZE	16
+
+/**
+ * enum sgx_attributes - the attributes field in &struct sgx_secs
+ * %SGX_ATTR_INIT:		Enclave can be entered (is initialized).
+ * %SGX_ATTR_DEBUG:		Allow ENCLS(EDBGRD) and ENCLS(EDBGWR).
+ * %SGX_ATTR_MODE64BIT:		Tell that this a 64-bit enclave.
+ * %SGX_ATTR_PROVISIONKEY:      Allow to use provisioning keys for remote
+ *				attestation.
+ * %SGX_ATTR_KSS:		Allow to use key separation and sharing (KSS).
+ * %SGX_ATTR_EINITTOKENKEY:	Allow to use token signing key that is used to
+ *				sign cryptographic tokens that can be passed to
+ *				EINIT as an authorization to run an enclave.
+ */
+enum sgx_attribute {
+	SGX_ATTR_INIT		= BIT(0),
+	SGX_ATTR_DEBUG		= BIT(1),
+	SGX_ATTR_MODE64BIT	= BIT(2),
+	SGX_ATTR_PROVISIONKEY	= BIT(4),
+	SGX_ATTR_EINITTOKENKEY	= BIT(5),
+	SGX_ATTR_KSS		= BIT(7),
+};
+
+#define SGX_ATTR_RESERVED_MASK	(BIT_ULL(3) | BIT_ULL(6) | GENMASK_ULL(63, 8))
+
+/**
+ * struct sgx_secs - SGX Enclave Control Structure (SECS)
+ * @size:		size of the address space
+ * @base:		base address of the  address space
+ * @ssa_frame_size:	size of an SSA frame
+ * @miscselect:		additional information stored to an SSA frame
+ * @attributes:		attributes for enclave
+ * @xfrm:		XSave-Feature Request Mask (subset of XCR0)
+ * @mrenclave:		SHA256-hash of the enclave contents
+ * @mrsigner:		SHA256-hash of the public key used to sign the SIGSTRUCT
+ * @config_id:		a user-defined value that is used in key derivation
+ * @isv_prod_id:	a user-defined value that is used in key derivation
+ * @isv_svn:		a user-defined value that is used in key derivation
+ * @config_svn:		a user-defined value that is used in key derivation
+ *
+ * SGX Enclave Control Structure (SECS) is a special enclave page that is not
+ * visible in the address space. In fact, this structure defines the address
+ * range and other global attributes for the enclave and it is the first EPC
+ * page created for any enclave. It is moved from a temporary buffer to an EPC
+ * by the means of ENCLS(ECREATE) leaf.
+ */
+struct sgx_secs {
+	u64 size;
+	u64 base;
+	u32 ssa_frame_size;
+	u32 miscselect;
+	u8  reserved1[24];
+	u64 attributes;
+	u64 xfrm;
+	u32 mrenclave[8];
+	u8  reserved2[32];
+	u32 mrsigner[8];
+	u8  reserved3[32];
+	u32 config_id[16];
+	u16 isv_prod_id;
+	u16 isv_svn;
+	u16 config_svn;
+	u8  reserved4[3834];
+} __packed;
+
+/**
+ * enum sgx_tcs_flags - execution flags for TCS
+ * %SGX_TCS_DBGOPTIN:	If enabled allows single-stepping and breakpoints
+ *			inside an enclave. It is cleared by EADD but can
+ *			be set later with EDBGWR.
+ */
+enum sgx_tcs_flags {
+	SGX_TCS_DBGOPTIN	= 0x01,
+};
+
+#define SGX_TCS_RESERVED_MASK	GENMASK_ULL(63, 1)
+#define SGX_TCS_RESERVED_SIZE	4024
+
+/**
+ * struct sgx_tcs - Thread Control Structure (TCS)
+ * @state:		used to mark an entered TCS
+ * @flags:		execution flags (cleared by EADD)
+ * @ssa_offset:		SSA stack offset relative to the enclave base
+ * @ssa_index:		the current SSA frame index (cleard by EADD)
+ * @nr_ssa_frames:	the number of frame in the SSA stack
+ * @entry_offset:	entry point offset relative to the enclave base
+ * @exit_addr:		address outside the enclave to exit on an exception or
+ *			interrupt
+ * @fs_offset:		offset relative to the enclave base to become FS
+ *			segment inside the enclave
+ * @gs_offset:		offset relative to the enclave base to become GS
+ *			segment inside the enclave
+ * @fs_limit:		size to become a new FS-limit (only 32-bit enclaves)
+ * @gs_limit:		size to become a new GS-limit (only 32-bit enclaves)
+ *
+ * Thread Control Structure (TCS) is an enclave page visible in its address
+ * space that defines an entry point inside the enclave. A thread enters inside
+ * an enclave by supplying address of TCS to ENCLU(EENTER). A TCS can be entered
+ * by only one thread at a time.
+ */
+struct sgx_tcs {
+	u64 state;
+	u64 flags;
+	u64 ssa_offset;
+	u32 ssa_index;
+	u32 nr_ssa_frames;
+	u64 entry_offset;
+	u64 exit_addr;
+	u64 fs_offset;
+	u64 gs_offset;
+	u32 fs_limit;
+	u32 gs_limit;
+	u8  reserved[SGX_TCS_RESERVED_SIZE];
+} __packed;
+
+/**
+ * struct sgx_pageinfo - an enclave page descriptor
+ * @addr:	address of the enclave page
+ * @contents:	pointer to the page contents
+ * @metadata:	pointer either to a SECINFO or PCMD instance
+ * @secs:	address of the SECS page
+ */
+struct sgx_pageinfo {
+	u64 addr;
+	u64 contents;
+	u64 metadata;
+	u64 secs;
+} __packed __aligned(32);
+
+
+/**
+ * enum sgx_page_type - bits in the SECINFO flags defining the page type
+ * %SGX_PAGE_TYPE_SECS:	a SECS page
+ * %SGX_PAGE_TYPE_TCS:	a TCS page
+ * %SGX_PAGE_TYPE_REG:	a regular page
+ * %SGX_PAGE_TYPE_VA:	a VA page
+ * %SGX_PAGE_TYPE_TRIM:	a page in trimmed state
+ */
+enum sgx_page_type {
+	SGX_PAGE_TYPE_SECS,
+	SGX_PAGE_TYPE_TCS,
+	SGX_PAGE_TYPE_REG,
+	SGX_PAGE_TYPE_VA,
+	SGX_PAGE_TYPE_TRIM,
+};
+
+#define SGX_NR_PAGE_TYPES	5
+#define SGX_PAGE_TYPE_MASK	GENMASK(7, 0)
+
+/**
+ * enum sgx_secinfo_flags - the flags field in &struct sgx_secinfo
+ * %SGX_SECINFO_R:	allow read
+ * %SGX_SECINFO_W:	allow write
+ * %SGX_SECINFO_X:	allow execution
+ * %SGX_SECINFO_SECS:	a SECS page
+ * %SGX_SECINFO_TCS:	a TCS page
+ * %SGX_SECINFO_REG:	a regular page
+ * %SGX_SECINFO_VA:	a VA page
+ * %SGX_SECINFO_TRIM:	a page in trimmed state
+ */
+enum sgx_secinfo_flags {
+	SGX_SECINFO_R			= BIT(0),
+	SGX_SECINFO_W			= BIT(1),
+	SGX_SECINFO_X			= BIT(2),
+	SGX_SECINFO_SECS		= (SGX_PAGE_TYPE_SECS << 8),
+	SGX_SECINFO_TCS			= (SGX_PAGE_TYPE_TCS << 8),
+	SGX_SECINFO_REG			= (SGX_PAGE_TYPE_REG << 8),
+	SGX_SECINFO_VA			= (SGX_PAGE_TYPE_VA << 8),
+	SGX_SECINFO_TRIM		= (SGX_PAGE_TYPE_TRIM << 8),
+};
+
+#define SGX_SECINFO_PERMISSION_MASK	GENMASK_ULL(2, 0)
+#define SGX_SECINFO_PAGE_TYPE_MASK	(SGX_PAGE_TYPE_MASK << 8)
+#define SGX_SECINFO_RESERVED_MASK	~(SGX_SECINFO_PERMISSION_MASK | \
+					  SGX_SECINFO_PAGE_TYPE_MASK)
+
+/**
+ * struct sgx_secinfo - describes attributes of an EPC page
+ * @flags:	permissions and type
+ *
+ * Used together with ENCLS leaves that add or modify an EPC page to an
+ * enclave to define page permissions and type.
+ */
+struct sgx_secinfo {
+	u64 flags;
+	u8  reserved[56];
+} __packed __aligned(64);
+
+#define SGX_PCMD_RESERVED_SIZE 40
+
+/**
+ * struct sgx_pcmd - Paging Crypto Metadata (PCMD)
+ * @enclave_id:	enclave identifier
+ * @mac:	MAC over PCMD, page contents and isvsvn
+ *
+ * PCMD is stored for every swapped page to the regular memory. When ELDU loads
+ * the page back it recalculates the MAC by using a isvsvn number stored in a
+ * VA page. Together these two structures bring integrity and rollback
+ * protection.
+ */
+struct sgx_pcmd {
+	struct sgx_secinfo secinfo;
+	u64 enclave_id;
+	u8  reserved[SGX_PCMD_RESERVED_SIZE];
+	u8  mac[16];
+} __packed __aligned(128);
+
+#define SGX_SIGSTRUCT_RESERVED1_SIZE 84
+#define SGX_SIGSTRUCT_RESERVED2_SIZE 20
+#define SGX_SIGSTRUCT_RESERVED3_SIZE 32
+#define SGX_SIGSTRUCT_RESERVED4_SIZE 12
+
+/**
+ * struct sgx_sigstruct_header -  defines author of the enclave
+ * @header1:		constant byte string
+ * @vendor:		must be either 0x0000 or 0x8086
+ * @date:		YYYYMMDD in BCD
+ * @header2:		costant byte string
+ * @swdefined:		software defined value
+ */
+struct sgx_sigstruct_header {
+	u64 header1[2];
+	u32 vendor;
+	u32 date;
+	u64 header2[2];
+	u32 swdefined;
+	u8  reserved1[84];
+} __packed;
+
+/**
+ * struct sgx_sigstruct_body - defines contents of the enclave
+ * @miscselect:		additional information stored to an SSA frame
+ * @misc_mask:		required miscselect in SECS
+ * @attributes:		attributes for enclave
+ * @xfrm:		XSave-Feature Request Mask (subset of XCR0)
+ * @attributes_mask:	required attributes in SECS
+ * @xfrm_mask:		required XFRM in SECS
+ * @mrenclave:		SHA256-hash of the enclave contents
+ * @isvprodid:		a user-defined value that is used in key derivation
+ * @isvsvn:		a user-defined value that is used in key derivation
+ */
+struct sgx_sigstruct_body {
+	u32 miscselect;
+	u32 misc_mask;
+	u8  reserved2[20];
+	u64 attributes;
+	u64 xfrm;
+	u64 attributes_mask;
+	u64 xfrm_mask;
+	u8  mrenclave[32];
+	u8  reserved3[32];
+	u16 isvprodid;
+	u16 isvsvn;
+} __packed;
+
+/**
+ * struct sgx_sigstruct - an enclave signature
+ * @header:		defines author of the enclave
+ * @modulus:		the modulus of the public key
+ * @exponent:		the exponent of the public key
+ * @signature:		the signature calculated over the fields except modulus,
+ * @body:		defines contents of the enclave
+ * @q1:			a value used in RSA signature verification
+ * @q2:			a value used in RSA signature verification
+ *
+ * Header and body are the parts that are actual signed. The remaining fields
+ * define the signature of the enclave.
+ */
+struct sgx_sigstruct {
+	struct sgx_sigstruct_header header;
+	u8  modulus[SGX_MODULUS_SIZE];
+	u32 exponent;
+	u8  signature[SGX_MODULUS_SIZE];
+	struct sgx_sigstruct_body body;
+	u8  reserved4[12];
+	u8  q1[SGX_MODULUS_SIZE];
+	u8  q2[SGX_MODULUS_SIZE];
+} __packed;
+
+#define SGX_LAUNCH_TOKEN_SIZE 304
+
+#endif /* _ASM_X86_SGX_ARCH_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 05/24] x86/sgx: Add wrappers for ENCLS leaf functions
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (3 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 04/24] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 06/24] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
                   ` (18 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Darren Kenny,
	Sean Christopherson, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

ENCLS is a ring 0 instruction, which contains a set of leaf functions for
managing an enclave. Enclaves are measured and signed software entities,
which are protected by asserting the outside memory accesses and memory
encryption.

Add a two-layer macro system along with an encoding scheme to allow
wrappers to return trap numbers along ENCLS-specific error codes. The
bottom layer of the macro system splits between the leafs that return an
error code and those that do not. The second layer generates the correct
input/output annotations based on the number of operands for each leaf
function.

ENCLS leaf functions are documented in

  Intel SDM: 36.6 ENCLAVE INSTRUCTIONS AND INTEL®

Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/encls.h | 238 ++++++++++++++++++++++++++++++++
 1 file changed, 238 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/encls.h

diff --git a/arch/x86/kernel/cpu/sgx/encls.h b/arch/x86/kernel/cpu/sgx/encls.h
new file mode 100644
index 000000000000..a87f15ea5cca
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encls.h
@@ -0,0 +1,238 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+#ifndef _X86_ENCLS_H
+#define _X86_ENCLS_H
+
+#include <linux/bitops.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/rwsem.h>
+#include <linux/types.h>
+#include <asm/asm.h>
+#include <asm/traps.h>
+#include "sgx.h"
+
+enum sgx_encls_leaf {
+	ECREATE	= 0x00,
+	EADD	= 0x01,
+	EINIT	= 0x02,
+	EREMOVE	= 0x03,
+	EDGBRD	= 0x04,
+	EDGBWR	= 0x05,
+	EEXTEND	= 0x06,
+	ELDU	= 0x08,
+	EBLOCK	= 0x09,
+	EPA	= 0x0A,
+	EWB	= 0x0B,
+	ETRACK	= 0x0C,
+};
+
+/**
+ * ENCLS_FAULT_FLAG - flag signifying an ENCLS return code is a trapnr
+ *
+ * ENCLS has its own (positive value) error codes and also generates
+ * ENCLS specific #GP and #PF faults.  And the ENCLS values get munged
+ * with system error codes as everything percolates back up the stack.
+ * Unfortunately (for us), we need to precisely identify each unique
+ * error code, e.g. the action taken if EWB fails varies based on the
+ * type of fault and on the exact SGX error code, i.e. we can't simply
+ * convert all faults to -EFAULT.
+ *
+ * To make all three error types coexist, we set bit 30 to identify an
+ * ENCLS fault.  Bit 31 (technically bits N:31) is used to differentiate
+ * between positive (faults and SGX error codes) and negative (system
+ * error codes) values.
+ */
+#define ENCLS_FAULT_FLAG 0x40000000
+
+/* Retrieve the encoded trapnr from the specified return code. */
+#define ENCLS_TRAPNR(r) ((r) & ~ENCLS_FAULT_FLAG)
+
+/* Issue a WARN() about an ENCLS leaf. */
+#define ENCLS_WARN(r, name) {						  \
+	do {								  \
+		int _r = (r);						  \
+		WARN_ONCE(_r, "%s returned %d (0x%x)\n", (name), _r, _r); \
+	} while (0);							  \
+}
+
+/**
+ * encls_failed() - Check if an ENCLS leaf function failed
+ * @ret:	the return value of an ENCLS leaf function call
+ *
+ * Check if an ENCLS leaf function failed. This happens when the leaf function
+ * causes a fault that is not caused by an EPCM conflict or when the leaf
+ * function returns a non-zero value.
+ */
+static inline bool encls_failed(int ret)
+{
+	int epcm_trapnr;
+
+	if (boot_cpu_has(X86_FEATURE_SGX2))
+		epcm_trapnr = X86_TRAP_PF;
+	else
+		epcm_trapnr = X86_TRAP_GP;
+
+	if (ret & ENCLS_FAULT_FLAG)
+		return ENCLS_TRAPNR(ret) != epcm_trapnr;
+
+	return !!ret;
+}
+
+/**
+ * __encls_ret_N - encode an ENCLS leaf that returns an error code in EAX
+ * @rax:	leaf number
+ * @inputs:	asm inputs for the leaf
+ *
+ * Emit assembly for an ENCLS leaf that returns an error code, e.g. EREMOVE.
+ * And because SGX isn't complex enough as it is, leafs that return an error
+ * code also modify flags.
+ *
+ * Return:
+ *	0 on success,
+ *	SGX error code on failure
+ */
+#define __encls_ret_N(rax, inputs...)				\
+	({							\
+	int ret;						\
+	asm volatile(						\
+	"1: .byte 0x0f, 0x01, 0xcf;\n\t"			\
+	"2:\n"							\
+	".section .fixup,\"ax\"\n"				\
+	"3: orl $"__stringify(ENCLS_FAULT_FLAG)",%%eax\n"	\
+	"   jmp 2b\n"						\
+	".previous\n"						\
+	_ASM_EXTABLE_FAULT(1b, 3b)				\
+	: "=a"(ret)						\
+	: "a"(rax), inputs					\
+	: "memory", "cc");					\
+	ret;							\
+	})
+
+#define __encls_ret_1(rax, rcx)		\
+	({				\
+	__encls_ret_N(rax, "c"(rcx));	\
+	})
+
+#define __encls_ret_2(rax, rbx, rcx)		\
+	({					\
+	__encls_ret_N(rax, "b"(rbx), "c"(rcx));	\
+	})
+
+#define __encls_ret_3(rax, rbx, rcx, rdx)			\
+	({							\
+	__encls_ret_N(rax, "b"(rbx), "c"(rcx), "d"(rdx));	\
+	})
+
+/**
+ * __encls_N - encode an ENCLS leaf that doesn't return an error code
+ * @rax:	leaf number
+ * @rbx_out:	optional output variable
+ * @inputs:	asm inputs for the leaf
+ *
+ * Emit assembly for an ENCLS leaf that does not return an error code,
+ * e.g. ECREATE.  Leaves without error codes either succeed or fault.
+ * @rbx_out is an optional parameter for use by EDGBRD, which returns
+ * the requested value in RBX.
+ *
+ * Return:
+ *   0 on success,
+ *   trapnr with ENCLS_FAULT_FLAG set on fault
+ */
+#define __encls_N(rax, rbx_out, inputs...)			\
+	({							\
+	int ret;						\
+	asm volatile(						\
+	"1: .byte 0x0f, 0x01, 0xcf;\n\t"			\
+	"   xor %%eax,%%eax;\n"					\
+	"2:\n"							\
+	".section .fixup,\"ax\"\n"				\
+	"3: orl $"__stringify(ENCLS_FAULT_FLAG)",%%eax\n"	\
+	"   jmp 2b\n"						\
+	".previous\n"						\
+	_ASM_EXTABLE_FAULT(1b, 3b)				\
+	: "=a"(ret), "=b"(rbx_out)				\
+	: "a"(rax), inputs					\
+	: "memory");						\
+	ret;							\
+	})
+
+#define __encls_2(rax, rbx, rcx)				\
+	({							\
+	unsigned long ign_rbx_out;				\
+	__encls_N(rax, ign_rbx_out, "b"(rbx), "c"(rcx));	\
+	})
+
+#define __encls_1_1(rax, data, rcx)			\
+	({						\
+	unsigned long rbx_out;				\
+	int ret = __encls_N(rax, rbx_out, "c"(rcx));	\
+	if (!ret)					\
+		data = rbx_out;				\
+	ret;						\
+	})
+
+static inline int __ecreate(struct sgx_pageinfo *pginfo, void *secs)
+{
+	return __encls_2(ECREATE, pginfo, secs);
+}
+
+static inline int __eextend(void *secs, void *addr)
+{
+	return __encls_2(EEXTEND, secs, addr);
+}
+
+static inline int __eadd(struct sgx_pageinfo *pginfo, void *addr)
+{
+	return __encls_2(EADD, pginfo, addr);
+}
+
+static inline int __einit(void *sigstruct, void *token, void *secs)
+{
+	return __encls_ret_3(EINIT, sigstruct, secs, token);
+}
+
+static inline int __eremove(void *addr)
+{
+	return __encls_ret_1(EREMOVE, addr);
+}
+
+static inline int __edbgwr(void *addr, unsigned long *data)
+{
+	return __encls_2(EDGBWR, *data, addr);
+}
+
+static inline int __edbgrd(void *addr, unsigned long *data)
+{
+	return __encls_1_1(EDGBRD, *data, addr);
+}
+
+static inline int __etrack(void *addr)
+{
+	return __encls_ret_1(ETRACK, addr);
+}
+
+static inline int __eldu(struct sgx_pageinfo *pginfo, void *addr,
+			 void *va)
+{
+	return __encls_ret_3(ELDU, pginfo, addr, va);
+}
+
+static inline int __eblock(void *addr)
+{
+	return __encls_ret_1(EBLOCK, addr);
+}
+
+static inline int __epa(void *addr)
+{
+	unsigned long rbx = SGX_PAGE_TYPE_VA;
+
+	return __encls_2(EPA, rbx, addr);
+}
+
+static inline int __ewb(struct sgx_pageinfo *pginfo, void *addr,
+			void *va)
+{
+	return __encls_ret_3(EWB, pginfo, addr, va);
+}
+
+#endif /* _X86_ENCLS_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 06/24] x86/cpu/intel: Detect SGX support
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (4 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 05/24] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 07/24] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen
                   ` (17 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Jethro Beekman, Darren Kenny,
	Jarkko Sakkinen, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Configure SGX as part of feature control MSR initialization and update
the associated X86_FEATURE flags accordingly.  Because the kernel will
require the LE hash MSRs to be writable when running native enclaves,
disable X86_FEATURE_SGX (and all derivatives) if SGX Launch Control is
not (or cannot) be fully enabled via feature control MSR.

The check is done for every CPU, not just BSP, in order to verify that
MSR_IA32_FEATURE_CONTROL is correctly configured on all CPUs. The other
parts of the kernel, like the enclave driver, expect the same
configuration from all CPUs.

Note, unlike VMX, clear the X86_FEATURE_SGX* flags for all CPUs if any
CPU lacks SGX support as the kernel expects SGX to be available on all
CPUs.  X86_FEATURE_VMX is intentionally cleared only for the current CPU
so that KVM can provide additional information if KVM fails to load,
e.g. print which CPU doesn't support VMX.  KVM/VMX requires additional
per-CPU enabling, e.g. to set CR4.VMXE and do VMXON, and so already has
the necessary infrastructure to do per-CPU checks.  SGX on the other
hand doesn't require additional enabling, so clearing the feature flags
on all CPUs means the SGX subsystem doesn't need to manually do support
checks on a per-CPU basis.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/feat_ctl.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index 29a3bedabd06..c3afcd2e4342 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -93,16 +93,35 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c)
 }
 #endif /* CONFIG_X86_VMX_FEATURE_NAMES */
 
+static void clear_sgx_caps(void)
+{
+	setup_clear_cpu_cap(X86_FEATURE_SGX);
+	setup_clear_cpu_cap(X86_FEATURE_SGX_LC);
+	setup_clear_cpu_cap(X86_FEATURE_SGX1);
+	setup_clear_cpu_cap(X86_FEATURE_SGX2);
+}
+
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 {
 	bool tboot = tboot_enabled();
+	bool enable_sgx;
 	u64 msr;
 
 	if (rdmsrl_safe(MSR_IA32_FEAT_CTL, &msr)) {
 		clear_cpu_cap(c, X86_FEATURE_VMX);
+		clear_sgx_caps();
 		return;
 	}
 
+	/*
+	 * Enable SGX if and only if the kernel supports SGX and Launch Control
+	 * is supported, i.e. disable SGX if the LE hash MSRs can't be written.
+	 */
+	enable_sgx = cpu_has(c, X86_FEATURE_SGX) &&
+		     cpu_has(c, X86_FEATURE_SGX1) &&
+		     cpu_has(c, X86_FEATURE_SGX_LC) &&
+		     IS_ENABLED(CONFIG_INTEL_SGX);
+
 	if (msr & FEAT_CTL_LOCKED)
 		goto update_caps;
 
@@ -124,13 +143,16 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 			msr |= FEAT_CTL_VMX_ENABLED_INSIDE_SMX;
 	}
 
+	if (enable_sgx)
+		msr |= FEAT_CTL_SGX_ENABLED | FEAT_CTL_SGX_LC_ENABLED;
+
 	wrmsrl(MSR_IA32_FEAT_CTL, msr);
 
 update_caps:
 	set_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL);
 
 	if (!cpu_has(c, X86_FEATURE_VMX))
-		return;
+		goto update_sgx;
 
 	if ( (tboot && !(msr & FEAT_CTL_VMX_ENABLED_INSIDE_SMX)) ||
 	    (!tboot && !(msr & FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX))) {
@@ -143,4 +165,12 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 		init_vmx_capabilities(c);
 #endif
 	}
+
+update_sgx:
+	if (!(msr & FEAT_CTL_SGX_ENABLED) ||
+	    !(msr & FEAT_CTL_SGX_LC_ENABLED) || !enable_sgx) {
+		if (enable_sgx)
+			pr_err_once("SGX disabled by BIOS\n");
+		clear_sgx_caps();
+	}
 }
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 07/24] x86/cpu/intel: Add nosgx kernel parameter
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (5 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 06/24] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 08/24] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen
                   ` (16 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Sean Christopherson, Darren Kenny,
	akpm, andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

Add kernel parameter to disable Intel SGX kernel support.

Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 2 ++
 arch/x86/kernel/cpu/feat_ctl.c                  | 9 +++++++++
 2 files changed, 11 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a1068742a6df..e53448716567 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3339,6 +3339,8 @@
 
 	nosep		[BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
 
+	nosgx		[X86-64,SGX] Disables Intel SGX kernel support.
+
 	nosmp		[SMP] Tells an SMP kernel to act as a UP kernel,
 			and disable the IO APIC.  legacy for "maxcpus=0".
 
diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index c3afcd2e4342..1837df39527f 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -101,6 +101,15 @@ static void clear_sgx_caps(void)
 	setup_clear_cpu_cap(X86_FEATURE_SGX2);
 }
 
+static int __init nosgx(char *str)
+{
+	clear_sgx_caps();
+
+	return 0;
+}
+
+early_param("nosgx", nosgx);
+
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 {
 	bool tboot = tboot_enabled();
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 08/24] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (6 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 07/24] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 09/24] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen
                   ` (15 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Jethro Beekman, Darren Kenny,
	Serge Ayoun, Jarkko Sakkinen, akpm, andriy.shevchenko, asapek,
	bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Enumerate Enclave Page Cache (EPC) sections via CPUID and add the data
structures necessary to track EPC pages so that they can be easily borrowed
for different uses.

Embed section index to the first eight bits of the EPC page descriptor.
Existing client hardware supports only a single section, while upcoming
server hardware will support at most eight sections. Thus, eight bits
should be enough for long term needs.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/Kconfig                 |  17 +++
 arch/x86/kernel/cpu/Makefile     |   1 +
 arch/x86/kernel/cpu/sgx/Makefile |   2 +
 arch/x86/kernel/cpu/sgx/main.c   | 216 +++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/sgx.h    |  52 ++++++++
 5 files changed, 288 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/Makefile
 create mode 100644 arch/x86/kernel/cpu/sgx/main.c
 create mode 100644 arch/x86/kernel/cpu/sgx/sgx.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7101ac64bb20..90fe47577dd7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1927,6 +1927,23 @@ config X86_INTEL_TSX_MODE_AUTO
 	  side channel attacks- equals the tsx=auto command line parameter.
 endchoice
 
+config INTEL_SGX
+	bool "Intel SGX"
+	depends on X86_64 && CPU_SUP_INTEL
+	depends on CRYPTO=y
+	depends on CRYPTO_SHA256=y
+	select SRCU
+	select MMU_NOTIFIER
+	help
+	  Intel(R) Software Guard eXtensions (SGX) is a set of CPU instructions
+	  that can be used by applications to set aside private regions of code
+	  and data, referred to as enclaves. An enclave's private memory can
+	  only be accessed by code running within the enclave. Accesses from
+	  outside the enclave, including other enclaves, are disallowed by
+	  hardware.
+
+	  If unsure, say N.
+
 config EFI
 	bool "EFI runtime service support"
 	depends on ACPI
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 93792b457b81..c80d804fd02b 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_X86_MCE)			+= mce/
 obj-$(CONFIG_MTRR)			+= mtrr/
 obj-$(CONFIG_MICROCODE)			+= microcode/
 obj-$(CONFIG_X86_CPU_RESCTRL)		+= resctrl/
+obj-$(CONFIG_INTEL_SGX)			+= sgx/
 
 obj-$(CONFIG_X86_LOCAL_APIC)		+= perfctr-watchdog.o
 
diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
new file mode 100644
index 000000000000..79510ce01b3b
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -0,0 +1,2 @@
+obj-y += \
+	main.o
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
new file mode 100644
index 000000000000..c5831e3db14a
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-17 Intel Corporation.
+
+#include <linux/freezer.h>
+#include <linux/highmem.h>
+#include <linux/kthread.h>
+#include <linux/pagemap.h>
+#include <linux/ratelimit.h>
+#include <linux/sched/mm.h>
+#include <linux/sched/signal.h>
+#include <linux/slab.h>
+#include "encls.h"
+
+struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
+static int sgx_nr_epc_sections;
+static struct task_struct *ksgxswapd_tsk;
+
+static void sgx_sanitize_section(struct sgx_epc_section *section)
+{
+	struct sgx_epc_page *page;
+	LIST_HEAD(secs_list);
+	int ret;
+
+	while (!list_empty(&section->unsanitized_page_list)) {
+		if (kthread_should_stop())
+			return;
+
+		spin_lock(&section->lock);
+
+		page = list_first_entry(&section->unsanitized_page_list,
+					struct sgx_epc_page, list);
+
+		ret = __eremove(sgx_get_epc_addr(page));
+		if (!ret)
+			list_move(&page->list, &section->page_list);
+		else
+			list_move_tail(&page->list, &secs_list);
+
+		spin_unlock(&section->lock);
+
+		cond_resched();
+	}
+}
+
+static int ksgxswapd(void *p)
+{
+	int i;
+
+	set_freezable();
+
+	/*
+	 * Reset all pages to uninitialized state. Pages could be in initialized
+	 * on kmemexec.
+	 */
+	for (i = 0; i < sgx_nr_epc_sections; i++)
+		sgx_sanitize_section(&sgx_epc_sections[i]);
+
+	/*
+	 * 2nd round for the SECS pages as they cannot be removed when they
+	 * still hold child pages.
+	 */
+	for (i = 0; i < sgx_nr_epc_sections; i++) {
+		sgx_sanitize_section(&sgx_epc_sections[i]);
+
+		/* Should never happen. */
+		if (!list_empty(&sgx_epc_sections[i].unsanitized_page_list))
+			WARN(1, "EPC section %d has unsanitized pages.\n", i);
+	}
+
+	return 0;
+}
+
+static bool __init sgx_page_reclaimer_init(void)
+{
+	struct task_struct *tsk;
+
+	tsk = kthread_run(ksgxswapd, NULL, "ksgxswapd");
+	if (IS_ERR(tsk))
+		return false;
+
+	ksgxswapd_tsk = tsk;
+
+	return true;
+}
+
+static void __init sgx_free_epc_section(struct sgx_epc_section *section)
+{
+	struct sgx_epc_page *page;
+
+	while (!list_empty(&section->page_list)) {
+		page = list_first_entry(&section->page_list,
+					struct sgx_epc_page, list);
+		list_del(&page->list);
+		kfree(page);
+	}
+
+	while (!list_empty(&section->unsanitized_page_list)) {
+		page = list_first_entry(&section->unsanitized_page_list,
+					struct sgx_epc_page, list);
+		list_del(&page->list);
+		kfree(page);
+	}
+
+	memunmap(section->va);
+}
+
+static bool __init sgx_setup_epc_section(u64 addr, u64 size,
+					 unsigned long index,
+					 struct sgx_epc_section *section)
+{
+	unsigned long nr_pages = size >> PAGE_SHIFT;
+	struct sgx_epc_page *page;
+	unsigned long i;
+
+	section->va = memremap(addr, size, MEMREMAP_WB);
+	if (!section->va)
+		return false;
+
+	section->pa = addr;
+	spin_lock_init(&section->lock);
+	INIT_LIST_HEAD(&section->page_list);
+	INIT_LIST_HEAD(&section->unsanitized_page_list);
+
+	for (i = 0; i < nr_pages; i++) {
+		page = kzalloc(sizeof(*page), GFP_KERNEL);
+		if (!page)
+			goto err_out;
+
+		page->desc = (addr + (i << PAGE_SHIFT)) | index;
+		list_add_tail(&page->list, &section->unsanitized_page_list);
+	}
+
+	return true;
+
+err_out:
+	sgx_free_epc_section(section);
+	return false;
+}
+
+static void __init sgx_page_cache_teardown(void)
+{
+	int i;
+
+	for (i = 0; i < sgx_nr_epc_sections; i++)
+		sgx_free_epc_section(&sgx_epc_sections[i]);
+}
+
+/**
+ * A section metric is concatenated in a way that @low bits 12-31 define the
+ * bits 12-31 of the metric and @high bits 0-19 define the bits 32-51 of the
+ * metric.
+ */
+static inline u64 __init sgx_calc_section_metric(u64 low, u64 high)
+{
+	return (low & GENMASK_ULL(31, 12)) +
+	       ((high & GENMASK_ULL(19, 0)) << 32);
+}
+
+static bool __init sgx_page_cache_init(void)
+{
+	u32 eax, ebx, ecx, edx, type;
+	u64 pa, size;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(sgx_epc_sections); i++) {
+		cpuid_count(SGX_CPUID, i + SGX_CPUID_FIRST_VARIABLE_SUB_LEAF,
+			    &eax, &ebx, &ecx, &edx);
+
+		type = eax & SGX_CPUID_SUB_LEAF_TYPE_MASK;
+		if (type == SGX_CPUID_SUB_LEAF_INVALID)
+			break;
+
+		if (type != SGX_CPUID_SUB_LEAF_EPC_SECTION) {
+			pr_err_once("Unknown EPC section type: %u\n", type);
+			break;
+		}
+
+		pa = sgx_calc_section_metric(eax, ebx);
+		size = sgx_calc_section_metric(ecx, edx);
+
+		pr_info("EPC section 0x%llx-0x%llx\n", pa, pa + size - 1);
+
+		if (!sgx_setup_epc_section(pa, size, i, &sgx_epc_sections[i])) {
+			pr_err("No free memory for an EPC section\n");
+			break;
+		}
+
+		sgx_nr_epc_sections++;
+	}
+
+	if (!sgx_nr_epc_sections) {
+		pr_err("There are zero EPC sections.\n");
+		return false;
+	}
+
+	return true;
+}
+
+static void __init sgx_init(void)
+{
+	if (!boot_cpu_has(X86_FEATURE_SGX))
+		return;
+
+	if (!sgx_page_cache_init())
+		return;
+
+	if (!sgx_page_reclaimer_init())
+		goto err_page_cache;
+
+	return;
+
+err_page_cache:
+	sgx_page_cache_teardown();
+}
+
+device_initcall(sgx_init);
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
new file mode 100644
index 000000000000..dff4f5f16d09
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+#ifndef _X86_SGX_H
+#define _X86_SGX_H
+
+#include <linux/bitops.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/rwsem.h>
+#include <linux/types.h>
+#include <asm/asm.h>
+#include "arch.h"
+
+#undef pr_fmt
+#define pr_fmt(fmt) "sgx: " fmt
+
+struct sgx_epc_page {
+	unsigned long desc;
+	struct list_head list;
+};
+
+/*
+ * The firmware can define multiple chunks of EPC to the different areas of the
+ * physical memory e.g. for memory areas of the each node. This structure is
+ * used to store EPC pages for one EPC section and virtual memory area where
+ * the pages have been mapped.
+ */
+struct sgx_epc_section {
+	unsigned long pa;
+	void *va;
+	struct list_head page_list;
+	struct list_head unsanitized_page_list;
+	spinlock_t lock;
+};
+
+#define SGX_EPC_SECTION_MASK		GENMASK(7, 0)
+#define SGX_MAX_EPC_SECTIONS		(SGX_EPC_SECTION_MASK + 1)
+
+extern struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
+
+static inline struct sgx_epc_section *sgx_get_epc_section(struct sgx_epc_page *page)
+{
+	return &sgx_epc_sections[page->desc & SGX_EPC_SECTION_MASK];
+}
+
+static inline void *sgx_get_epc_addr(struct sgx_epc_page *page)
+{
+	struct sgx_epc_section *section = sgx_get_epc_section(page);
+
+	return section->va + (page->desc & PAGE_MASK) - section->pa;
+}
+
+#endif /* _X86_SGX_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 09/24] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page()
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (7 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 08/24] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
                   ` (14 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Darren Kenny,
	Sean Christopherson, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

Add __sgx_alloc_epc_page(), which iterates through EPC sections and borrows
a page structure that is not used by anyone else. When a page is no longer
needed it must be released with sgx_free_epc_page(). This function
implicitly calls ENCLS[EREMOVE], which will return the page to the
uninitialized state (i.e. not required from caller part).

Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/main.c | 62 ++++++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/sgx.h  |  3 ++
 2 files changed, 65 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index c5831e3db14a..97c6895fb6c9 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -83,6 +83,68 @@ static bool __init sgx_page_reclaimer_init(void)
 	return true;
 }
 
+static struct sgx_epc_page *__sgx_alloc_epc_page_from_section(struct sgx_epc_section *section)
+{
+	struct sgx_epc_page *page;
+
+	if (list_empty(&section->page_list))
+		return NULL;
+
+	page = list_first_entry(&section->page_list, struct sgx_epc_page, list);
+	list_del_init(&page->list);
+
+	return page;
+}
+
+/**
+ * __sgx_alloc_epc_page() - Allocate an EPC page
+ *
+ * Iterate through EPC sections and borrow a free EPC page to the caller. When a
+ * page is no longer needed it must be released with sgx_free_epc_page().
+ *
+ * Return:
+ *   an EPC page,
+ *   -errno on error
+ */
+struct sgx_epc_page *__sgx_alloc_epc_page(void)
+{
+	struct sgx_epc_section *section;
+	struct sgx_epc_page *page;
+	int i;
+
+	for (i = 0; i < sgx_nr_epc_sections; i++) {
+		section = &sgx_epc_sections[i];
+		spin_lock(&section->lock);
+		page = __sgx_alloc_epc_page_from_section(section);
+		spin_unlock(&section->lock);
+
+		if (page)
+			return page;
+	}
+
+	return ERR_PTR(-ENOMEM);
+}
+
+/**
+ * sgx_free_epc_page() - Free an EPC page
+ * @page:	an EPC page
+ *
+ * Call EREMOVE for an EPC page and insert it back to the list of free pages.
+ */
+void sgx_free_epc_page(struct sgx_epc_page *page)
+{
+	struct sgx_epc_section *section = sgx_get_epc_section(page);
+	int ret;
+
+	ret = __eremove(sgx_get_epc_addr(page));
+	if (WARN_ONCE(ret, "EREMOVE returned %d (0x%x)", ret, ret))
+		return;
+
+	spin_lock(&section->lock);
+	list_add_tail(&page->list, &section->page_list);
+	spin_unlock(&section->lock);
+}
+
 static void __init sgx_free_epc_section(struct sgx_epc_section *section)
 {
 	struct sgx_epc_page *page;
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index dff4f5f16d09..fce756c3434b 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -49,4 +49,7 @@ static inline void *sgx_get_epc_addr(struct sgx_epc_page *page)
 	return section->va + (page->desc & PAGE_MASK) - section->pa;
 }
 
+struct sgx_epc_page *__sgx_alloc_epc_page(void);
+void sgx_free_epc_page(struct sgx_epc_page *page);
+
 #endif /* _X86_SGX_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (8 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 09/24] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-18 12:44   ` Borislav Petkov
  2020-09-18 15:09   ` Andy Lutomirski
  2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
                   ` (13 subsequent siblings)
  23 siblings, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, linux-mm, Andrew Morton,
	Matthew Wilcox, Jethro Beekman, Darren Kenny, Jarkko Sakkinen,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Add vm_ops()->mprotect() for additional constraints for a VMA.

Intel Software Guard eXtensions (SGX) will use this callback to add two
constraints:

1. Verify that the address range does not have holes: each page address
   must be filled with an enclave page.
2. Verify that VMA permissions won't surpass the permissions of any enclave
   page within the address range. Enclave cryptographically sealed
   permissions for each page address that set the upper limit for possible
   VMA permissions. Not respecting this can cause #GP's to be emitted.

Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 include/linux/mm.h | 3 +++
 mm/mprotect.c      | 5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 97c83773b6f0..717726fcace6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -547,6 +547,9 @@ struct vm_operations_struct {
 	void (*close)(struct vm_area_struct * area);
 	int (*split)(struct vm_area_struct * area, unsigned long addr);
 	int (*mremap)(struct vm_area_struct * area);
+	int (*mprotect)(struct vm_area_struct *vma,
+			struct vm_area_struct **pprev, unsigned long start,
+			unsigned long end, unsigned long newflags);
 	vm_fault_t (*fault)(struct vm_fault *vmf);
 	vm_fault_t (*huge_fault)(struct vm_fault *vmf,
 			enum page_entry_size pe_size);
diff --git a/mm/mprotect.c b/mm/mprotect.c
index ce8b8a5eacbb..f170f3da8a4f 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -610,7 +610,10 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
 		tmp = vma->vm_end;
 		if (tmp > end)
 			tmp = end;
-		error = mprotect_fixup(vma, &prev, nstart, tmp, newflags);
+		if (vma->vm_ops && vma->vm_ops->mprotect)
+			error = vma->vm_ops->mprotect(vma, &prev, nstart, tmp, newflags);
+		else
+			error = mprotect_fixup(vma, &prev, nstart, tmp, newflags);
 		if (error)
 			goto out;
 		nstart = tmp;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 11/24] x86/sgx: Add SGX enclave driver
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (9 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-21  9:30   ` Borislav Petkov
  2020-10-01 17:36   ` Sean Christopherson
  2020-09-15 11:28 ` [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
                   ` (12 subsequent siblings)
  23 siblings, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, linux-security-module, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

Intel Software Guard eXtensions (SGX) is a set of CPU instructions that can
be used by applications to set aside private regions of code and data. The
code outside the SGX hosted software entity is prevented from accessing the
memory inside the enclave by the CPU. We call these entities as enclaves.

Add a driver that provides an ioctl API to construct and run enclaves.
Enclaves are constructed from pages residing in reserved physical memory
areas. The contents of these pages can only be accessed when they are
mapped as part of an enclave, by a hardware thread running inside the
enclave.

The starting state of an enclave consists of a fixed measured set of
pages that are copied to the EPC during the construction process by
using the opcode ENCLS leaf functions and Software Enclave Control
Structure (SECS) that defines the enclave properties.

Enclaves are constructed by using ENCLS leaf functions ECREATE, EADD and
EINIT. ECREATE initializes SECS, EADD copies pages from system memory to
the EPC and EINIT checks a given signed measurement and moves the enclave
into a state ready for execution.

An initialized enclave can only be accessed through special Thread Control
Structure (TCS) pages by using ENCLU (ring-3 only) leaf EENTER.  This leaf
function converts a thread into enclave mode and continues the execution in
the offset defined by the TCS provided to EENTER. An enclave is exited
through syscall, exception, interrupts or by explicitly calling another
ENCLU leaf EEXIT.

The mmap() permissions are capped by the contained enclave page
permissions. The mapped areas must also be populated, i.e. each page
address must contain a page. This logic is implemented in
sgx_encl_may_map().

Cc: linux-security-module@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
Tested-by: Seth Moore <sethmo@google.com>
Tested-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/Makefile |   2 +
 arch/x86/kernel/cpu/sgx/driver.c | 173 ++++++++++++++++
 arch/x86/kernel/cpu/sgx/driver.h |  29 +++
 arch/x86/kernel/cpu/sgx/encl.c   | 331 +++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/encl.h   |  85 ++++++++
 arch/x86/kernel/cpu/sgx/main.c   |  11 +
 6 files changed, 631 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.c
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.h
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.h

diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
index 79510ce01b3b..3fc451120735 100644
--- a/arch/x86/kernel/cpu/sgx/Makefile
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -1,2 +1,4 @@
 obj-y += \
+	driver.o \
+	encl.o \
 	main.o
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
new file mode 100644
index 000000000000..f54da5f19c2b
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#include <linux/acpi.h>
+#include <linux/miscdevice.h>
+#include <linux/mman.h>
+#include <linux/security.h>
+#include <linux/suspend.h>
+#include <asm/traps.h>
+#include "driver.h"
+#include "encl.h"
+
+u64 sgx_encl_size_max_32;
+u64 sgx_encl_size_max_64;
+u32 sgx_misc_reserved_mask;
+u64 sgx_attributes_reserved_mask;
+u64 sgx_xfrm_reserved_mask = ~0x3;
+u32 sgx_xsave_size_tbl[64];
+
+static int sgx_open(struct inode *inode, struct file *file)
+{
+	struct sgx_encl *encl;
+	int ret;
+
+	encl = kzalloc(sizeof(*encl), GFP_KERNEL);
+	if (!encl)
+		return -ENOMEM;
+
+	atomic_set(&encl->flags, 0);
+	kref_init(&encl->refcount);
+	xa_init(&encl->page_array);
+	mutex_init(&encl->lock);
+	INIT_LIST_HEAD(&encl->mm_list);
+	spin_lock_init(&encl->mm_lock);
+
+	ret = init_srcu_struct(&encl->srcu);
+	if (ret) {
+		kfree(encl);
+		return ret;
+	}
+
+	file->private_data = encl;
+
+	return 0;
+}
+
+static int sgx_release(struct inode *inode, struct file *file)
+{
+	struct sgx_encl *encl = file->private_data;
+	struct sgx_encl_mm *encl_mm;
+
+	for ( ; ; )  {
+		spin_lock(&encl->mm_lock);
+
+		if (list_empty(&encl->mm_list)) {
+			encl_mm = NULL;
+		} else {
+			encl_mm = list_first_entry(&encl->mm_list,
+						   struct sgx_encl_mm, list);
+			list_del_rcu(&encl_mm->list);
+		}
+
+		spin_unlock(&encl->mm_lock);
+
+		/* The list is empty, ready to go. */
+		if (!encl_mm)
+			break;
+
+		synchronize_srcu(&encl->srcu);
+		mmu_notifier_unregister(&encl_mm->mmu_notifier, encl_mm->mm);
+		kfree(encl_mm);
+	}
+
+	mutex_lock(&encl->lock);
+	atomic_or(SGX_ENCL_DEAD, &encl->flags);
+	mutex_unlock(&encl->lock);
+
+	kref_put(&encl->refcount, sgx_encl_release);
+	return 0;
+}
+
+static int sgx_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	struct sgx_encl *encl = file->private_data;
+	int ret;
+
+	ret = sgx_encl_may_map(encl, vma->vm_start, vma->vm_end, vma->vm_flags);
+	if (ret)
+		return ret;
+
+	ret = sgx_encl_mm_add(encl, vma->vm_mm);
+	if (ret)
+		return ret;
+
+	vma->vm_ops = &sgx_vm_ops;
+	vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
+	vma->vm_private_data = encl;
+
+	return 0;
+}
+
+static unsigned long sgx_get_unmapped_area(struct file *file,
+					   unsigned long addr,
+					   unsigned long len,
+					   unsigned long pgoff,
+					   unsigned long flags)
+{
+	if ((flags & MAP_TYPE) == MAP_PRIVATE)
+		return -EINVAL;
+
+	if (flags & MAP_FIXED)
+		return addr;
+
+	return current->mm->get_unmapped_area(file, addr, len, pgoff, flags);
+}
+
+static const struct file_operations sgx_encl_fops = {
+	.owner			= THIS_MODULE,
+	.open			= sgx_open,
+	.release		= sgx_release,
+	.mmap			= sgx_mmap,
+	.get_unmapped_area	= sgx_get_unmapped_area,
+};
+
+static struct miscdevice sgx_dev_enclave = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "enclave",
+	.nodename = "sgx/enclave",
+	.fops = &sgx_encl_fops,
+};
+
+int __init sgx_drv_init(void)
+{
+	unsigned int eax, ebx, ecx, edx;
+	u64 attr_mask, xfrm_mask;
+	int ret;
+	int i;
+
+	if (!boot_cpu_has(X86_FEATURE_SGX_LC)) {
+		pr_info("The public key MSRs are not writable.\n");
+		return -ENODEV;
+	}
+
+	cpuid_count(SGX_CPUID, 0, &eax, &ebx, &ecx, &edx);
+	sgx_misc_reserved_mask = ~ebx | SGX_MISC_RESERVED_MASK;
+	sgx_encl_size_max_64 = 1ULL << ((edx >> 8) & 0xFF);
+	sgx_encl_size_max_32 = 1ULL << (edx & 0xFF);
+
+	cpuid_count(SGX_CPUID, 1, &eax, &ebx, &ecx, &edx);
+
+	attr_mask = (((u64)ebx) << 32) + (u64)eax;
+	sgx_attributes_reserved_mask = ~attr_mask | SGX_ATTR_RESERVED_MASK;
+
+	if (boot_cpu_has(X86_FEATURE_OSXSAVE)) {
+		xfrm_mask = (((u64)edx) << 32) + (u64)ecx;
+
+		for (i = 2; i < 64; i++) {
+			cpuid_count(0x0D, i, &eax, &ebx, &ecx, &edx);
+			if ((1UL << i) & xfrm_mask)
+				sgx_xsave_size_tbl[i] = eax + ebx;
+		}
+
+		sgx_xfrm_reserved_mask = ~xfrm_mask;
+	}
+
+	ret = misc_register(&sgx_dev_enclave);
+	if (ret) {
+		pr_err("Creating /dev/sgx/enclave failed with %d.\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
new file mode 100644
index 000000000000..f7ce40dedc91
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+#ifndef __ARCH_SGX_DRIVER_H__
+#define __ARCH_SGX_DRIVER_H__
+
+#include <crypto/hash.h>
+#include <linux/kref.h>
+#include <linux/mmu_notifier.h>
+#include <linux/radix-tree.h>
+#include <linux/rwsem.h>
+#include <linux/sched.h>
+#include <linux/workqueue.h>
+#include "sgx.h"
+
+#define SGX_EINIT_SPIN_COUNT	20
+#define SGX_EINIT_SLEEP_COUNT	50
+#define SGX_EINIT_SLEEP_TIME	20
+
+extern u64 sgx_encl_size_max_32;
+extern u64 sgx_encl_size_max_64;
+extern u32 sgx_misc_reserved_mask;
+extern u64 sgx_attributes_reserved_mask;
+extern u64 sgx_xfrm_reserved_mask;
+extern u32 sgx_xsave_size_tbl[64];
+
+long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
+
+int sgx_drv_init(void);
+
+#endif /* __ARCH_X86_SGX_DRIVER_H__ */
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
new file mode 100644
index 000000000000..c2c4a77af36b
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#include <linux/lockdep.h>
+#include <linux/mm.h>
+#include <linux/mman.h>
+#include <linux/shmem_fs.h>
+#include <linux/suspend.h>
+#include <linux/sched/mm.h>
+#include "arch.h"
+#include "encl.h"
+#include "encls.h"
+#include "sgx.h"
+
+static struct sgx_encl_page *sgx_encl_load_page(struct sgx_encl *encl,
+						unsigned long addr)
+{
+	struct sgx_encl_page *entry;
+	unsigned int flags;
+
+	/* If process was forked, VMA is still there but vm_private_data is set
+	 * to NULL.
+	 */
+	if (!encl)
+		return ERR_PTR(-EFAULT);
+
+	flags = atomic_read(&encl->flags);
+	if ((flags & SGX_ENCL_DEAD) || !(flags & SGX_ENCL_INITIALIZED))
+		return ERR_PTR(-EFAULT);
+
+	entry = xa_load(&encl->page_array, PFN_DOWN(addr));
+	if (!entry)
+		return ERR_PTR(-EFAULT);
+
+	/* Page is already resident in the EPC. */
+	if (entry->epc_page)
+		return entry;
+
+	return ERR_PTR(-EFAULT);
+}
+
+static void sgx_mmu_notifier_release(struct mmu_notifier *mn,
+				     struct mm_struct *mm)
+{
+	struct sgx_encl_mm *encl_mm = container_of(mn, struct sgx_encl_mm, mmu_notifier);
+	struct sgx_encl_mm *tmp = NULL;
+
+	/*
+	 * The enclave itself can remove encl_mm.  Note, objects can't be moved
+	 * off an RCU protected list, but deletion is ok.
+	 */
+	spin_lock(&encl_mm->encl->mm_lock);
+	list_for_each_entry(tmp, &encl_mm->encl->mm_list, list) {
+		if (tmp == encl_mm) {
+			list_del_rcu(&encl_mm->list);
+			break;
+		}
+	}
+	spin_unlock(&encl_mm->encl->mm_lock);
+
+	if (tmp == encl_mm) {
+		synchronize_srcu(&encl_mm->encl->srcu);
+		mmu_notifier_put(mn);
+	}
+}
+
+static void sgx_mmu_notifier_free(struct mmu_notifier *mn)
+{
+	struct sgx_encl_mm *encl_mm = container_of(mn, struct sgx_encl_mm, mmu_notifier);
+
+	kfree(encl_mm);
+}
+
+static const struct mmu_notifier_ops sgx_mmu_notifier_ops = {
+	.release		= sgx_mmu_notifier_release,
+	.free_notifier		= sgx_mmu_notifier_free,
+};
+
+static struct sgx_encl_mm *sgx_encl_find_mm(struct sgx_encl *encl,
+					    struct mm_struct *mm)
+{
+	struct sgx_encl_mm *encl_mm = NULL;
+	struct sgx_encl_mm *tmp;
+	int idx;
+
+	idx = srcu_read_lock(&encl->srcu);
+
+	list_for_each_entry_rcu(tmp, &encl->mm_list, list) {
+		if (tmp->mm == mm) {
+			encl_mm = tmp;
+			break;
+		}
+	}
+
+	srcu_read_unlock(&encl->srcu, idx);
+
+	return encl_mm;
+}
+
+int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm)
+{
+	struct sgx_encl_mm *encl_mm;
+	int ret;
+
+	/* mm_list can be accessed only by a single thread at a time. */
+	mmap_assert_write_locked(mm);
+
+	if (atomic_read(&encl->flags) & SGX_ENCL_DEAD)
+		return -EINVAL;
+
+	/*
+	 * mm_structs are kept on mm_list until the mm or the enclave dies,
+	 * i.e. once an mm is off the list, it's gone for good, therefore it's
+	 * impossible to get a false positive on @mm due to a stale mm_list.
+	 */
+	if (sgx_encl_find_mm(encl, mm))
+		return 0;
+
+	encl_mm = kzalloc(sizeof(*encl_mm), GFP_KERNEL);
+	if (!encl_mm)
+		return -ENOMEM;
+
+	encl_mm->encl = encl;
+	encl_mm->mm = mm;
+	encl_mm->mmu_notifier.ops = &sgx_mmu_notifier_ops;
+
+	ret = __mmu_notifier_register(&encl_mm->mmu_notifier, mm);
+	if (ret) {
+		kfree(encl_mm);
+		return ret;
+	}
+
+	spin_lock(&encl->mm_lock);
+	list_add_rcu(&encl_mm->list, &encl->mm_list);
+	spin_unlock(&encl->mm_lock);
+
+	return 0;
+}
+
+static void sgx_vma_open(struct vm_area_struct *vma)
+{
+	struct sgx_encl *encl = vma->vm_private_data;
+
+	if (!encl)
+		return;
+
+	if (sgx_encl_mm_add(encl, vma->vm_mm))
+		vma->vm_private_data = NULL;
+}
+
+static unsigned int sgx_vma_fault(struct vm_fault *vmf)
+{
+	unsigned long addr = (unsigned long)vmf->address;
+	struct vm_area_struct *vma = vmf->vma;
+	struct sgx_encl *encl = vma->vm_private_data;
+	struct sgx_encl_page *entry;
+	int ret = VM_FAULT_NOPAGE;
+	unsigned long pfn;
+
+	if (!encl)
+		return VM_FAULT_SIGBUS;
+
+	mutex_lock(&encl->lock);
+
+	entry = sgx_encl_load_page(encl, addr);
+	if (IS_ERR(entry)) {
+		if (unlikely(PTR_ERR(entry) != -EBUSY))
+			ret = VM_FAULT_SIGBUS;
+
+		goto out;
+	}
+
+	if (!follow_pfn(vma, addr, &pfn))
+		goto out;
+
+	ret = vmf_insert_pfn(vma, addr, PFN_DOWN(entry->epc_page->desc));
+	if (ret != VM_FAULT_NOPAGE) {
+		ret = VM_FAULT_SIGBUS;
+		goto out;
+	}
+
+out:
+	mutex_unlock(&encl->lock);
+	return ret;
+}
+
+/**
+ * sgx_encl_may_map() - Check if a requested VMA mapping is allowed
+ * @encl:		an enclave pointer
+ * @start:		lower bound of the address range, inclusive
+ * @end:		upper bound of the address range, exclusive
+ * @vm_prot_bits:	requested protections of the address range
+ *
+ * Iterate through the enclave pages contained within [@start, @end) to verify
+ * the permissions requested by @vm_prot_bits do not exceed that of any enclave
+ * page to be mapped.
+ *
+ * Return:
+ *   0 on success,
+ *   -EACCES if VMA permissions exceed enclave page permissions
+ */
+int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
+		     unsigned long end, unsigned long vm_flags)
+{
+	unsigned long vm_prot_bits = vm_flags & (VM_READ | VM_WRITE | VM_EXEC);
+	unsigned long idx_start = PFN_DOWN(start);
+	unsigned long idx_end = PFN_DOWN(end - 1);
+	struct sgx_encl_page *page;
+
+	XA_STATE(xas, &encl->page_array, idx_start);
+
+	/*
+	 * Disallow READ_IMPLIES_EXEC tasks as their VMA permissions might
+	 * conflict with the enclave page permissions.
+	 */
+	if (current->personality & READ_IMPLIES_EXEC)
+		return -EACCES;
+
+	xas_for_each(&xas, page, idx_end)
+		if (!page || (~page->vm_max_prot_bits & vm_prot_bits))
+			return -EACCES;
+
+	return 0;
+}
+
+static int sgx_vma_mprotect(struct vm_area_struct *vma,
+			    struct vm_area_struct **pprev, unsigned long start,
+			    unsigned long end, unsigned long newflags)
+{
+	int ret;
+
+	ret = sgx_encl_may_map(vma->vm_private_data, start, end, newflags);
+	if (ret)
+		return ret;
+
+	return mprotect_fixup(vma, pprev, start, end, newflags);
+}
+
+const struct vm_operations_struct sgx_vm_ops = {
+	.open = sgx_vma_open,
+	.fault = sgx_vma_fault,
+	.mprotect = sgx_vma_mprotect,
+};
+
+/**
+ * sgx_encl_find - find an enclave
+ * @mm:		mm struct of the current process
+ * @addr:	address in the ELRANGE
+ * @vma:	the resulting VMA
+ *
+ * Find an enclave identified by the given address. Give back a VMA that is
+ * part of the enclave and located in that address. The VMA is given back if it
+ * is a proper enclave VMA even if an &sgx_encl instance does not exist yet
+ * (enclave creation has not been performed).
+ *
+ * Return:
+ *   0 on success,
+ *   -EINVAL if an enclave was not found,
+ *   -ENOENT if the enclave has not been created yet
+ */
+int sgx_encl_find(struct mm_struct *mm, unsigned long addr,
+		  struct vm_area_struct **vma)
+{
+	struct vm_area_struct *result;
+	struct sgx_encl *encl;
+
+	result = find_vma(mm, addr);
+	if (!result || result->vm_ops != &sgx_vm_ops || addr < result->vm_start)
+		return -EINVAL;
+
+	encl = result->vm_private_data;
+	*vma = result;
+
+	return encl ? 0 : -ENOENT;
+}
+
+/**
+ * sgx_encl_destroy() - destroy enclave resources
+ * @encl:	an enclave pointer
+ */
+void sgx_encl_destroy(struct sgx_encl *encl)
+{
+	struct sgx_encl_page *entry;
+	unsigned long index;
+
+	atomic_or(SGX_ENCL_DEAD, &encl->flags);
+
+	xa_for_each(&encl->page_array, index, entry) {
+		if (entry->epc_page) {
+			sgx_free_epc_page(entry->epc_page);
+			encl->secs_child_cnt--;
+			entry->epc_page = NULL;
+		}
+
+		kfree(entry);
+	}
+
+	xa_destroy(&encl->page_array);
+
+	if (!encl->secs_child_cnt && encl->secs.epc_page) {
+		sgx_free_epc_page(encl->secs.epc_page);
+		encl->secs.epc_page = NULL;
+	}
+}
+
+/**
+ * sgx_encl_release - Destroy an enclave instance
+ * @kref:	address of a kref inside &sgx_encl
+ *
+ * Used together with kref_put(). Frees all the resources associated with the
+ * enclave and the instance itself.
+ */
+void sgx_encl_release(struct kref *ref)
+{
+	struct sgx_encl *encl = container_of(ref, struct sgx_encl, refcount);
+
+	sgx_encl_destroy(encl);
+
+	if (encl->backing)
+		fput(encl->backing);
+
+	cleanup_srcu_struct(&encl->srcu);
+
+	WARN_ON_ONCE(!list_empty(&encl->mm_list));
+
+	/* Detect EPC page leak's. */
+	WARN_ON_ONCE(encl->secs_child_cnt);
+	WARN_ON_ONCE(encl->secs.epc_page);
+
+	kfree(encl);
+}
diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
new file mode 100644
index 000000000000..8ff445476657
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encl.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+#ifndef _X86_ENCL_H
+#define _X86_ENCL_H
+
+#include <linux/cpumask.h>
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/mm_types.h>
+#include <linux/mmu_notifier.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/srcu.h>
+#include <linux/workqueue.h>
+#include <linux/xarray.h>
+#include "sgx.h"
+
+/**
+ * enum sgx_encl_page_desc - defines bits for an enclave page's descriptor
+ * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
+ *
+ * The page address for SECS is zero and is used by the subsystem to recognize
+ * the SECS page.
+ */
+enum sgx_encl_page_desc {
+	/* Bits 11:3 are available when the page is not swapped. */
+	SGX_ENCL_PAGE_ADDR_MASK		= PAGE_MASK,
+};
+
+#define SGX_ENCL_PAGE_ADDR(page) \
+	((page)->desc & SGX_ENCL_PAGE_ADDR_MASK)
+
+struct sgx_encl_page {
+	unsigned long desc;
+	unsigned long vm_max_prot_bits;
+	struct sgx_epc_page *epc_page;
+	struct sgx_encl *encl;
+};
+
+enum sgx_encl_flags {
+	SGX_ENCL_CREATED	= BIT(0),
+	SGX_ENCL_INITIALIZED	= BIT(1),
+	SGX_ENCL_DEBUG		= BIT(2),
+	SGX_ENCL_DEAD		= BIT(3),
+	SGX_ENCL_IOCTL		= BIT(4),
+};
+
+struct sgx_encl_mm {
+	struct sgx_encl *encl;
+	struct mm_struct *mm;
+	struct list_head list;
+	struct mmu_notifier mmu_notifier;
+};
+
+struct sgx_encl {
+	atomic_t flags;
+	unsigned int page_cnt;
+	unsigned int secs_child_cnt;
+	struct mutex lock;
+	struct list_head mm_list;
+	spinlock_t mm_lock;
+	struct file *backing;
+	struct kref refcount;
+	struct srcu_struct srcu;
+	unsigned long base;
+	unsigned long size;
+	unsigned long ssaframesize;
+	struct xarray page_array;
+	struct sgx_encl_page secs;
+	cpumask_t cpumask;
+};
+
+extern const struct vm_operations_struct sgx_vm_ops;
+
+int sgx_encl_find(struct mm_struct *mm, unsigned long addr,
+		  struct vm_area_struct **vma);
+void sgx_encl_destroy(struct sgx_encl *encl);
+void sgx_encl_release(struct kref *ref);
+int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm);
+int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
+		     unsigned long end, unsigned long vm_flags);
+
+#endif /* _X86_ENCL_H */
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 97c6895fb6c9..4137254fb29e 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -9,6 +9,8 @@
 #include <linux/sched/mm.h>
 #include <linux/sched/signal.h>
 #include <linux/slab.h>
+#include "driver.h"
+#include "encl.h"
 #include "encls.h"
 
 struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
@@ -260,6 +262,8 @@ static bool __init sgx_page_cache_init(void)
 
 static void __init sgx_init(void)
 {
+	int ret;
+
 	if (!boot_cpu_has(X86_FEATURE_SGX))
 		return;
 
@@ -269,8 +273,15 @@ static void __init sgx_init(void)
 	if (!sgx_page_reclaimer_init())
 		goto err_page_cache;
 
+	ret = sgx_drv_init();
+	if (ret)
+		goto err_kthread;
+
 	return;
 
+err_kthread:
+	kthread_stop(ksgxswapd_tsk);
+
 err_page_cache:
 	sgx_page_cache_teardown();
 }
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (10 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-21 10:03   ` Borislav Petkov
  2020-10-03  0:23   ` Haitao Huang
  2020-09-15 11:28 ` [PATCH v38 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES Jarkko Sakkinen
                   ` (11 subsequent siblings)
  23 siblings, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

Add an ioctl that performs ENCLS[ECREATE], which creates SGX Enclave
Control Structure for the enclave. SECS contains attributes about the
enclave that are used by the hardware and cannot be directly accessed by
software, as SECS resides in the EPC.

One essential field in SECS is a field that stores the SHA256 of the
measured enclave pages. This field, MRENCLAVE, is initialized by the
ECREATE instruction and updated by every EADD and EEXTEND operation.
Finally, EINIT locks down the value.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
Tested-by: Seth Moore <sethmo@google.com>
Tested-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 arch/x86/include/uapi/asm/sgx.h               |  25 ++
 arch/x86/kernel/cpu/sgx/Makefile              |   1 +
 arch/x86/kernel/cpu/sgx/driver.c              |  12 +
 arch/x86/kernel/cpu/sgx/driver.h              |   1 +
 arch/x86/kernel/cpu/sgx/ioctl.c               | 220 ++++++++++++++++++
 6 files changed, 260 insertions(+)
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 arch/x86/kernel/cpu/sgx/ioctl.c

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 2a198838fca9..a89e1c46a25a 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -323,6 +323,7 @@ Code  Seq#    Include File                                           Comments
                                                                      <mailto:tlewis@mindspring.com>
 0xA3  90-9F  linux/dtlk.h
 0xA4  00-1F  uapi/linux/tee.h                                        Generic TEE subsystem
+0xA4  00-1F  uapi/asm/sgx.h                                          <mailto:linux-sgx@vger.kernel.org>
 0xAA  00-3F  linux/uapi/linux/userfaultfd.h
 0xAB  00-1F  linux/nbd.h
 0xAC  00-1F  linux/raw.h
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
new file mode 100644
index 000000000000..c75b375f3770
--- /dev/null
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) */
+/*
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+#ifndef _UAPI_ASM_X86_SGX_H
+#define _UAPI_ASM_X86_SGX_H
+
+#include <linux/types.h>
+#include <linux/ioctl.h>
+
+#define SGX_MAGIC 0xA4
+
+#define SGX_IOC_ENCLAVE_CREATE \
+	_IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
+
+/**
+ * struct sgx_enclave_create - parameter structure for the
+ *                             %SGX_IOC_ENCLAVE_CREATE ioctl
+ * @src:	address for the SECS page data
+ */
+struct sgx_enclave_create  {
+	__u64	src;
+};
+
+#endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
index 3fc451120735..91d3dc784a29 100644
--- a/arch/x86/kernel/cpu/sgx/Makefile
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -1,4 +1,5 @@
 obj-y += \
 	driver.o \
 	encl.o \
+	ioctl.o \
 	main.o
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index f54da5f19c2b..7bdb49dfcca6 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -114,10 +114,22 @@ static unsigned long sgx_get_unmapped_area(struct file *file,
 	return current->mm->get_unmapped_area(file, addr, len, pgoff, flags);
 }
 
+#ifdef CONFIG_COMPAT
+static long sgx_compat_ioctl(struct file *filep, unsigned int cmd,
+			      unsigned long arg)
+{
+	return sgx_ioctl(filep, cmd, arg);
+}
+#endif
+
 static const struct file_operations sgx_encl_fops = {
 	.owner			= THIS_MODULE,
 	.open			= sgx_open,
 	.release		= sgx_release,
+	.unlocked_ioctl		= sgx_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl		= sgx_compat_ioctl,
+#endif
 	.mmap			= sgx_mmap,
 	.get_unmapped_area	= sgx_get_unmapped_area,
 };
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
index f7ce40dedc91..e4063923115b 100644
--- a/arch/x86/kernel/cpu/sgx/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -9,6 +9,7 @@
 #include <linux/rwsem.h>
 #include <linux/sched.h>
 #include <linux/workqueue.h>
+#include <uapi/asm/sgx.h>
 #include "sgx.h"
 
 #define SGX_EINIT_SPIN_COUNT	20
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
new file mode 100644
index 000000000000..352a3c461812
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-19 Intel Corporation.
+
+#include <asm/mman.h>
+#include <linux/mman.h>
+#include <linux/delay.h>
+#include <linux/file.h>
+#include <linux/hashtable.h>
+#include <linux/highmem.h>
+#include <linux/ratelimit.h>
+#include <linux/sched/signal.h>
+#include <linux/shmem_fs.h>
+#include <linux/slab.h>
+#include <linux/suspend.h>
+#include "driver.h"
+#include "encl.h"
+#include "encls.h"
+
+static u32 sgx_calc_ssa_frame_size(u32 miscselect, u64 xfrm)
+{
+	u32 size_max = PAGE_SIZE;
+	u32 size;
+	int i;
+
+	for (i = 2; i < 64; i++) {
+		if (!((1 << i) & xfrm))
+			continue;
+
+		size = SGX_SSA_GPRS_SIZE + sgx_xsave_size_tbl[i];
+
+		if (miscselect & SGX_MISC_EXINFO)
+			size += SGX_SSA_MISC_EXINFO_SIZE;
+
+		if (size > size_max)
+			size_max = size;
+	}
+
+	return PFN_UP(size_max);
+}
+
+static int sgx_validate_secs(const struct sgx_secs *secs)
+{
+	u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
+		       sgx_encl_size_max_64 : sgx_encl_size_max_32;
+
+	if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
+		return -EINVAL;
+
+	if (secs->base & (secs->size - 1))
+		return -EINVAL;
+
+	if (secs->miscselect & sgx_misc_reserved_mask ||
+	    secs->attributes & sgx_attributes_reserved_mask ||
+	    secs->xfrm & sgx_xfrm_reserved_mask)
+		return -EINVAL;
+
+	if (secs->size > max_size)
+		return -EINVAL;
+
+	if (!(secs->xfrm & XFEATURE_MASK_FP) ||
+	    !(secs->xfrm & XFEATURE_MASK_SSE) ||
+	    (((secs->xfrm >> XFEATURE_BNDREGS) & 1) !=
+	     ((secs->xfrm >> XFEATURE_BNDCSR) & 1)))
+		return -EINVAL;
+
+	if (!secs->ssa_frame_size)
+		return -EINVAL;
+
+	if (sgx_calc_ssa_frame_size(secs->miscselect, secs->xfrm) >
+	    secs->ssa_frame_size)
+		return -EINVAL;
+
+	if (memchr_inv(secs->reserved1, 0, sizeof(secs->reserved1)) ||
+	    memchr_inv(secs->reserved2, 0, sizeof(secs->reserved2)) ||
+	    memchr_inv(secs->reserved3, 0, sizeof(secs->reserved3)) ||
+	    memchr_inv(secs->reserved4, 0, sizeof(secs->reserved4)))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
+{
+	unsigned long encl_size = secs->size + PAGE_SIZE;
+	struct sgx_epc_page *secs_epc;
+	struct sgx_pageinfo pginfo;
+	struct sgx_secinfo secinfo;
+	struct file *backing;
+	long ret;
+
+	if (sgx_validate_secs(secs)) {
+		pr_debug("invalid SECS\n");
+		return -EINVAL;
+	}
+
+	backing = shmem_file_setup("SGX backing", encl_size + (encl_size >> 5),
+				   VM_NORESERVE);
+	if (IS_ERR(backing))
+		return PTR_ERR(backing);
+
+	encl->backing = backing;
+
+	secs_epc = __sgx_alloc_epc_page();
+	if (IS_ERR(secs_epc)) {
+		ret = PTR_ERR(secs_epc);
+		goto err_out_backing;
+	}
+
+	encl->secs.epc_page = secs_epc;
+
+	pginfo.addr = 0;
+	pginfo.contents = (unsigned long)secs;
+	pginfo.metadata = (unsigned long)&secinfo;
+	pginfo.secs = 0;
+	memset(&secinfo, 0, sizeof(secinfo));
+
+	ret = __ecreate((void *)&pginfo, sgx_get_epc_addr(secs_epc));
+	if (ret) {
+		pr_debug("ECREATE returned %ld\n", ret);
+		goto err_out;
+	}
+
+	if (secs->attributes & SGX_ATTR_DEBUG)
+		atomic_or(SGX_ENCL_DEBUG, &encl->flags);
+
+	encl->secs.encl = encl;
+	encl->base = secs->base;
+	encl->size = secs->size;
+	encl->ssaframesize = secs->ssa_frame_size;
+
+	/*
+	 * Set SGX_ENCL_CREATED only after the enclave is fully prepped.  This
+	 * allows setting and checking enclave creation without having to take
+	 * encl->lock.
+	 */
+	atomic_or(SGX_ENCL_CREATED, &encl->flags);
+
+	return 0;
+
+err_out:
+	sgx_free_epc_page(encl->secs.epc_page);
+	encl->secs.epc_page = NULL;
+
+err_out_backing:
+	fput(encl->backing);
+	encl->backing = NULL;
+
+	return ret;
+}
+
+/**
+ * sgx_ioc_enclave_create - handler for %SGX_IOC_ENCLAVE_CREATE
+ * @filep:	open file to /dev/sgx
+ * @arg:	userspace pointer to a struct sgx_enclave_create instance
+ *
+ * Allocate kernel data structures for a new enclave and execute ECREATE after
+ * verifying the correctness of the provided SECS.
+ *
+ * Return:
+ *   0 on success,
+ *   -errno otherwise
+ */
+static long sgx_ioc_enclave_create(struct sgx_encl *encl, void __user *arg)
+{
+	struct sgx_enclave_create ecreate;
+	struct page *secs_page;
+	struct sgx_secs *secs;
+	int ret;
+
+	if (atomic_read(&encl->flags) & SGX_ENCL_CREATED)
+		return -EINVAL;
+
+	if (copy_from_user(&ecreate, arg, sizeof(ecreate)))
+		return -EFAULT;
+
+	secs_page = alloc_page(GFP_KERNEL);
+	if (!secs_page)
+		return -ENOMEM;
+
+	secs = kmap(secs_page);
+	if (copy_from_user(secs, (void __user *)ecreate.src, sizeof(*secs))) {
+		ret = -EFAULT;
+		goto out;
+	}
+
+	ret = sgx_encl_create(encl, secs);
+
+out:
+	kunmap(secs_page);
+	__free_page(secs_page);
+	return ret;
+}
+
+long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
+{
+	struct sgx_encl *encl = filep->private_data;
+	int ret, encl_flags;
+
+	encl_flags = atomic_fetch_or(SGX_ENCL_IOCTL, &encl->flags);
+	if (encl_flags & SGX_ENCL_IOCTL)
+		return -EBUSY;
+
+	if (encl_flags & SGX_ENCL_DEAD) {
+		ret = -EFAULT;
+		goto out;
+	}
+
+	switch (cmd) {
+	case SGX_IOC_ENCLAVE_CREATE:
+		ret = sgx_ioc_enclave_create(encl, (void __user *)arg);
+		break;
+	default:
+		ret = -ENOIOCTLCMD;
+		break;
+	}
+
+out:
+	atomic_andnot(SGX_ENCL_IOCTL, &encl->flags);
+	return ret;
+}
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (11 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT Jarkko Sakkinen
                   ` (10 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

Add an ioctl, which performs ENCLS[EADD] that adds new visible page to an
enclave, and optionally ENCLS[EEXTEND] operations that hash the page to the
enclave measurement. By visible we mean a page that can be mapped to the
address range of an enclave.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
Tested-by: Seth Moore <sethmo@google.com>
Tested-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/uapi/asm/sgx.h |  28 +++
 arch/x86/kernel/cpu/sgx/ioctl.c | 294 ++++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/sgx.h   |   1 +
 3 files changed, 323 insertions(+)

diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index c75b375f3770..c42a2ad3ca0b 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -8,10 +8,21 @@
 #include <linux/types.h>
 #include <linux/ioctl.h>
 
+/**
+ * enum sgx_epage_flags - page control flags
+ * %SGX_PAGE_MEASURE:	Measure the page contents with a sequence of
+ *			ENCLS[EEXTEND] operations.
+ */
+enum sgx_page_flags {
+	SGX_PAGE_MEASURE	= 0x01,
+};
+
 #define SGX_MAGIC 0xA4
 
 #define SGX_IOC_ENCLAVE_CREATE \
 	_IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
+#define SGX_IOC_ENCLAVE_ADD_PAGES \
+	_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
 
 /**
  * struct sgx_enclave_create - parameter structure for the
@@ -22,4 +33,21 @@ struct sgx_enclave_create  {
 	__u64	src;
 };
 
+/**
+ * struct sgx_enclave_add_pages - parameter structure for the
+ *                                %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
+ * @src:	start address for the page data
+ * @offset:	starting page offset
+ * @length:	length of the data (multiple of the page size)
+ * @secinfo:	address for the SECINFO data
+ * @flags:	page control flags
+ */
+struct sgx_enclave_add_pages {
+	__u64	src;
+	__u64	offset;
+	__u64	length;
+	__u64	secinfo;
+	__u64	flags;
+};
+
 #endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 352a3c461812..202680a06c17 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -191,6 +191,297 @@ static long sgx_ioc_enclave_create(struct sgx_encl *encl, void __user *arg)
 	return ret;
 }
 
+static struct sgx_encl_page *sgx_encl_page_alloc(struct sgx_encl *encl,
+						 unsigned long offset,
+						 u64 secinfo_flags)
+{
+	struct sgx_encl_page *encl_page;
+	unsigned long prot;
+
+	encl_page = kzalloc(sizeof(*encl_page), GFP_KERNEL);
+	if (!encl_page)
+		return ERR_PTR(-ENOMEM);
+
+	encl_page->desc = encl->base + offset;
+	encl_page->encl = encl;
+
+	prot = _calc_vm_trans(secinfo_flags, SGX_SECINFO_R, PROT_READ)  |
+	       _calc_vm_trans(secinfo_flags, SGX_SECINFO_W, PROT_WRITE) |
+	       _calc_vm_trans(secinfo_flags, SGX_SECINFO_X, PROT_EXEC);
+
+	/*
+	 * TCS pages must always RW set for CPU access while the SECINFO
+	 * permissions are *always* zero - the CPU ignores the user provided
+	 * values and silently overwrites them with zero permissions.
+	 */
+	if ((secinfo_flags & SGX_SECINFO_PAGE_TYPE_MASK) == SGX_SECINFO_TCS)
+		prot |= PROT_READ | PROT_WRITE;
+
+	/* Calculate maximum of the VM flags for the page. */
+	encl_page->vm_max_prot_bits = calc_vm_prot_bits(prot, 0);
+
+	return encl_page;
+}
+
+static int sgx_validate_secinfo(struct sgx_secinfo *secinfo)
+{
+	u64 perm = secinfo->flags & SGX_SECINFO_PERMISSION_MASK;
+	u64 pt = secinfo->flags & SGX_SECINFO_PAGE_TYPE_MASK;
+
+	if (pt != SGX_SECINFO_REG && pt != SGX_SECINFO_TCS)
+		return -EINVAL;
+
+	if ((perm & SGX_SECINFO_W) && !(perm & SGX_SECINFO_R))
+		return -EINVAL;
+
+	/*
+	 * CPU will silently overwrite the permissions as zero, which means
+	 * that we need to validate it ourselves.
+	 */
+	if (pt == SGX_SECINFO_TCS && perm)
+		return -EINVAL;
+
+	if (secinfo->flags & SGX_SECINFO_RESERVED_MASK)
+		return -EINVAL;
+
+	if (memchr_inv(secinfo->reserved, 0, sizeof(secinfo->reserved)))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int __sgx_encl_add_page(struct sgx_encl *encl,
+			       struct sgx_encl_page *encl_page,
+			       struct sgx_epc_page *epc_page,
+			       struct sgx_secinfo *secinfo, unsigned long src)
+{
+	struct sgx_pageinfo pginfo;
+	struct vm_area_struct *vma;
+	struct page *src_page;
+	int ret;
+
+	/* Query vma's VM_MAYEXEC as an indirect path_noexec() check. */
+	if (encl_page->vm_max_prot_bits & VM_EXEC) {
+		vma = find_vma(current->mm, src);
+		if (!vma)
+			return -EFAULT;
+
+		if (!(vma->vm_flags & VM_MAYEXEC))
+			return -EACCES;
+	}
+
+	ret = get_user_pages(src, 1, 0, &src_page, NULL);
+	if (ret < 1)
+		return ret;
+
+	pginfo.secs = (unsigned long)sgx_get_epc_addr(encl->secs.epc_page);
+	pginfo.addr = SGX_ENCL_PAGE_ADDR(encl_page);
+	pginfo.metadata = (unsigned long)secinfo;
+	pginfo.contents = (unsigned long)kmap_atomic(src_page);
+
+	ret = __eadd(&pginfo, sgx_get_epc_addr(epc_page));
+
+	kunmap_atomic((void *)pginfo.contents);
+	put_page(src_page);
+
+	return ret ? -EIO : 0;
+}
+
+/*
+ * If the caller requires measurement of the page as a proof for the content,
+ * use EEXTEND to add a measurement for 256 bytes of the page. Repeat this
+ * operation until the entire page is measured."
+ */
+static int __sgx_encl_extend(struct sgx_encl *encl,
+			     struct sgx_epc_page *epc_page)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < 16; i++) {
+		ret = __eextend(sgx_get_epc_addr(encl->secs.epc_page),
+				sgx_get_epc_addr(epc_page) + (i * 0x100));
+		if (ret) {
+			if (encls_failed(ret))
+				ENCLS_WARN(ret, "EEXTEND");
+			return -EIO;
+		}
+	}
+
+	return 0;
+}
+
+static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
+			     unsigned long offset, struct sgx_secinfo *secinfo,
+			     unsigned long flags)
+{
+	struct sgx_encl_page *encl_page;
+	struct sgx_epc_page *epc_page;
+	int ret;
+
+	encl_page = sgx_encl_page_alloc(encl, offset, secinfo->flags);
+	if (IS_ERR(encl_page))
+		return PTR_ERR(encl_page);
+
+	epc_page = __sgx_alloc_epc_page();
+	if (IS_ERR(epc_page)) {
+		kfree(encl_page);
+		return PTR_ERR(epc_page);
+	}
+
+	mmap_read_lock(current->mm);
+	mutex_lock(&encl->lock);
+
+	/*
+	 * Insert prior to EADD in case of OOM.  EADD modifies MRENCLAVE, i.e.
+	 * can't be gracefully unwound, while failure on EADD/EXTEND is limited
+	 * to userspace errors (or kernel/hardware bugs).
+	 */
+	ret = xa_insert(&encl->page_array, PFN_DOWN(encl_page->desc),
+			encl_page, GFP_KERNEL);
+	if (ret)
+		goto err_out_unlock;
+
+	ret = __sgx_encl_add_page(encl, encl_page, epc_page, secinfo,
+				  src);
+	if (ret)
+		goto err_out;
+
+	/*
+	 * Complete the "add" before doing the "extend" so that the "add"
+	 * isn't in a half-baked state in the extremely unlikely scenario
+	 * the enclave will be destroyed in response to EEXTEND failure.
+	 */
+	encl_page->encl = encl;
+	encl_page->epc_page = epc_page;
+	encl->secs_child_cnt++;
+
+	if (flags & SGX_PAGE_MEASURE) {
+		ret = __sgx_encl_extend(encl, epc_page);
+		if (ret)
+			goto err_out;
+	}
+
+	mutex_unlock(&encl->lock);
+	mmap_read_unlock(current->mm);
+	return ret;
+
+err_out:
+	xa_erase(&encl->page_array, PFN_DOWN(encl_page->desc));
+
+err_out_unlock:
+	mutex_unlock(&encl->lock);
+	mmap_read_unlock(current->mm);
+
+	sgx_free_epc_page(epc_page);
+	kfree(encl_page);
+
+	/*
+	 * Destroy enclave on ENCLS failure as this means that EPC has been
+	 * invalidated.
+	 */
+	if (ret == -EIO) {
+		mutex_lock(&encl->lock);
+		sgx_encl_destroy(encl);
+		mutex_unlock(&encl->lock);
+	}
+
+	return ret;
+}
+
+/**
+ * sgx_ioc_enclave_add_pages() - The handler for %SGX_IOC_ENCLAVE_ADD_PAGES
+ * @encl:       an enclave pointer
+ * @arg:	a user pointer to a struct sgx_enclave_add_pages instance
+ *
+ * Add one or more pages to an uninitialized enclave, and optionally extend the
+ * measurement with the contents of the page. The SECINFO and measurement mask
+ * are applied to all pages.
+ *
+ * A SECINFO for a TCS is required to always contain zero permissions because
+ * CPU silently zeros them. Allowing anything else would cause a mismatch in
+ * the measurement.
+ *
+ * mmap()'s protection bits are capped by the page permissions. For each page
+ * address, the maximum protection bits are computed with the following
+ * heuristics:
+ *
+ * 1. A regular page: PROT_R, PROT_W and PROT_X match the SECINFO permissions.
+ * 2. A TCS page: PROT_R | PROT_W.
+ *
+ * mmap() is not allowed to surpass the minimum of the maximum protection bits
+ * within the given address range.
+ *
+ * If ENCLS opcode fails, that effectively means that EPC has been invalidated.
+ * When this happens the enclave is destroyed and -EIO is returned to the
+ * caller.
+ *
+ * Return:
+ *   length of the data processed on success,
+ *   -EACCES if an executable source page is located in a noexec partition,
+ *   -EIO if either ENCLS[EADD] or ENCLS[EEXTEND] fails
+ *   -errno otherwise
+ */
+static long sgx_ioc_enclave_add_pages(struct sgx_encl *encl, void __user *arg)
+{
+	struct sgx_enclave_add_pages addp;
+	struct sgx_secinfo secinfo;
+	unsigned long c;
+	int ret;
+
+	if ((atomic_read(&encl->flags) & SGX_ENCL_INITIALIZED) ||
+	    !(atomic_read(&encl->flags) & SGX_ENCL_CREATED))
+		return -EINVAL;
+
+	if (copy_from_user(&addp, arg, sizeof(addp)))
+		return -EFAULT;
+
+	if (!IS_ALIGNED(addp.offset, PAGE_SIZE) ||
+	    !IS_ALIGNED(addp.src, PAGE_SIZE))
+		return -EINVAL;
+
+	if (!(access_ok(addp.src, PAGE_SIZE)))
+		return -EFAULT;
+
+	if (addp.length & (PAGE_SIZE - 1))
+		return -EINVAL;
+
+	if (addp.offset + addp.length - PAGE_SIZE >= encl->size)
+		return -EINVAL;
+
+	if (copy_from_user(&secinfo, (void __user *)addp.secinfo,
+			   sizeof(secinfo)))
+		return -EFAULT;
+
+	if (sgx_validate_secinfo(&secinfo))
+		return -EINVAL;
+
+	for (c = 0 ; c < addp.length; c += PAGE_SIZE) {
+		if (signal_pending(current)) {
+			if (!c)
+				ret = -EINTR;
+
+			break;
+		}
+
+		if (c == SGX_MAX_ADD_PAGES_LENGTH)
+			break;
+
+		if (need_resched())
+			cond_resched();
+
+		ret = sgx_encl_add_page(encl, addp.src + c, addp.offset + c,
+					&secinfo, addp.flags);
+		if (ret)
+			break;
+	}
+
+	if (ret)
+		return ret;
+
+	return c;
+}
+
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 {
 	struct sgx_encl *encl = filep->private_data;
@@ -209,6 +500,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 	case SGX_IOC_ENCLAVE_CREATE:
 		ret = sgx_ioc_enclave_create(encl, (void __user *)arg);
 		break;
+	case SGX_IOC_ENCLAVE_ADD_PAGES:
+		ret = sgx_ioc_enclave_add_pages(encl, (void __user *)arg);
+		break;
 	default:
 		ret = -ENOIOCTLCMD;
 		break;
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index fce756c3434b..8d126070db1e 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -34,6 +34,7 @@ struct sgx_epc_section {
 
 #define SGX_EPC_SECTION_MASK		GENMASK(7, 0)
 #define SGX_MAX_EPC_SECTIONS		(SGX_EPC_SECTION_MASK + 1)
+#define SGX_MAX_ADD_PAGES_LENGTH	0x100000
 
 extern struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (12 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-21 17:35   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation Jarkko Sakkinen
                   ` (9 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

Add an ioctl that performs ENCLS[EINIT], which locks down the measurement
and initializes the enclave for entrance. After this, new pages can no
longer be added.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
Tested-by: Seth Moore <sethmo@google.com>
Tested-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/uapi/asm/sgx.h |  11 ++
 arch/x86/kernel/cpu/sgx/encl.h  |   2 +
 arch/x86/kernel/cpu/sgx/ioctl.c | 195 ++++++++++++++++++++++++++++++++
 3 files changed, 208 insertions(+)

diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index c42a2ad3ca0b..7729730d8580 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -23,6 +23,8 @@ enum sgx_page_flags {
 	_IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
 #define SGX_IOC_ENCLAVE_ADD_PAGES \
 	_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
+#define SGX_IOC_ENCLAVE_INIT \
+	_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
 
 /**
  * struct sgx_enclave_create - parameter structure for the
@@ -50,4 +52,13 @@ struct sgx_enclave_add_pages {
 	__u64	flags;
 };
 
+/**
+ * struct sgx_enclave_init - parameter structure for the
+ *                           %SGX_IOC_ENCLAVE_INIT ioctl
+ * @sigstruct:	address for the SIGSTRUCT data
+ */
+struct sgx_enclave_init {
+	__u64 sigstruct;
+};
+
 #endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
index 8ff445476657..0448d22d3010 100644
--- a/arch/x86/kernel/cpu/sgx/encl.h
+++ b/arch/x86/kernel/cpu/sgx/encl.h
@@ -70,6 +70,8 @@ struct sgx_encl {
 	struct xarray page_array;
 	struct sgx_encl_page secs;
 	cpumask_t cpumask;
+	unsigned long attributes;
+	unsigned long attributes_mask;
 };
 
 extern const struct vm_operations_struct sgx_vm_ops;
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 202680a06c17..de2ed4f35ffb 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -16,6 +16,9 @@
 #include "encl.h"
 #include "encls.h"
 
+/* A per-cpu cache for the last known values of IA32_SGXLEPUBKEYHASHx MSRs. */
+static DEFINE_PER_CPU(u64 [4], sgx_lepubkeyhash_cache);
+
 static u32 sgx_calc_ssa_frame_size(u32 miscselect, u64 xfrm)
 {
 	u32 size_max = PAGE_SIZE;
@@ -127,6 +130,9 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
 	encl->base = secs->base;
 	encl->size = secs->size;
 	encl->ssaframesize = secs->ssa_frame_size;
+	encl->attributes = secs->attributes;
+	encl->attributes_mask = SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT |
+				SGX_ATTR_KSS;
 
 	/*
 	 * Set SGX_ENCL_CREATED only after the enclave is fully prepped.  This
@@ -482,6 +488,192 @@ static long sgx_ioc_enclave_add_pages(struct sgx_encl *encl, void __user *arg)
 	return c;
 }
 
+static int __sgx_get_key_hash(struct crypto_shash *tfm, const void *modulus,
+			      void *hash)
+{
+	SHASH_DESC_ON_STACK(shash, tfm);
+
+	shash->tfm = tfm;
+
+	return crypto_shash_digest(shash, modulus, SGX_MODULUS_SIZE, hash);
+}
+
+static int sgx_get_key_hash(const void *modulus, void *hash)
+{
+	struct crypto_shash *tfm;
+	int ret;
+
+	tfm = crypto_alloc_shash("sha256", 0, CRYPTO_ALG_ASYNC);
+	if (IS_ERR(tfm))
+		return PTR_ERR(tfm);
+
+	ret = __sgx_get_key_hash(tfm, modulus, hash);
+
+	crypto_free_shash(tfm);
+	return ret;
+}
+
+static void sgx_update_lepubkeyhash_msrs(u64 *lepubkeyhash, bool enforce)
+{
+	u64 *cache;
+	int i;
+
+	cache = per_cpu(sgx_lepubkeyhash_cache, smp_processor_id());
+	for (i = 0; i < 4; i++) {
+		if (enforce || (lepubkeyhash[i] != cache[i])) {
+			wrmsrl(MSR_IA32_SGXLEPUBKEYHASH0 + i, lepubkeyhash[i]);
+			cache[i] = lepubkeyhash[i];
+		}
+	}
+}
+
+static int sgx_einit(struct sgx_sigstruct *sigstruct, void *token,
+		     struct sgx_epc_page *secs, u64 *lepubkeyhash)
+{
+	int ret;
+
+	preempt_disable();
+	sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);
+	ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
+	if (ret == SGX_INVALID_EINITTOKEN) {
+		sgx_update_lepubkeyhash_msrs(lepubkeyhash, true);
+		ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
+	}
+	preempt_enable();
+	return ret;
+}
+
+static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct *sigstruct,
+			 void *token)
+{
+	u64 mrsigner[4];
+	int ret;
+	int i;
+	int j;
+
+	/* Deny initializing enclaves with attributes (namely provisioning)
+	 * that have not been explicitly allowed.
+	 */
+	if (encl->attributes & ~encl->attributes_mask)
+		return -EACCES;
+
+	ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);
+	if (ret)
+		return ret;
+
+	mutex_lock(&encl->lock);
+
+	/*
+	 * ENCLS[EINIT] is interruptible because it has such a high latency,
+	 * e.g. 50k+ cycles on success. If an IRQ/NMI/SMI becomes pending,
+	 * EINIT may fail with SGX_UNMASKED_EVENT so that the event can be
+	 * serviced.
+	 */
+	for (i = 0; i < SGX_EINIT_SLEEP_COUNT; i++) {
+		for (j = 0; j < SGX_EINIT_SPIN_COUNT; j++) {
+			ret = sgx_einit(sigstruct, token, encl->secs.epc_page,
+					mrsigner);
+			if (ret == SGX_UNMASKED_EVENT)
+				continue;
+			else
+				break;
+		}
+
+		if (ret != SGX_UNMASKED_EVENT)
+			break;
+
+		msleep_interruptible(SGX_EINIT_SLEEP_TIME);
+
+		if (signal_pending(current)) {
+			ret = -ERESTARTSYS;
+			goto err_out;
+		}
+	}
+
+	if (ret & ENCLS_FAULT_FLAG) {
+		if (encls_failed(ret))
+			ENCLS_WARN(ret, "EINIT");
+
+		sgx_encl_destroy(encl);
+		ret = -EFAULT;
+	} else if (ret) {
+		pr_debug("EINIT returned %d\n", ret);
+		ret = -EPERM;
+	} else {
+		atomic_or(SGX_ENCL_INITIALIZED, &encl->flags);
+	}
+
+err_out:
+	mutex_unlock(&encl->lock);
+	return ret;
+}
+
+/**
+ * sgx_ioc_enclave_init - handler for %SGX_IOC_ENCLAVE_INIT
+ *
+ * @filep:	open file to /dev/sgx
+ * @arg:	userspace pointer to a struct sgx_enclave_init instance
+ *
+ * Flush any outstanding enqueued EADD operations and perform EINIT.  The
+ * Launch Enclave Public Key Hash MSRs are rewritten as necessary to match
+ * the enclave's MRSIGNER, which is caculated from the provided sigstruct.
+ *
+ * Return:
+ *   0 on success,
+ *   SGX error code on EINIT failure,
+ *   -errno otherwise
+ */
+static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
+{
+	struct sgx_sigstruct *sigstruct;
+	struct sgx_enclave_init einit;
+	struct page *initp_page;
+	void *token;
+	int ret;
+
+	if ((atomic_read(&encl->flags) & SGX_ENCL_INITIALIZED) ||
+	    !(atomic_read(&encl->flags) & SGX_ENCL_CREATED))
+		return -EINVAL;
+
+	if (copy_from_user(&einit, arg, sizeof(einit)))
+		return -EFAULT;
+
+	initp_page = alloc_page(GFP_KERNEL);
+	if (!initp_page)
+		return -ENOMEM;
+
+	sigstruct = kmap(initp_page);
+	token = (void *)((unsigned long)sigstruct + PAGE_SIZE / 2);
+	memset(token, 0, SGX_LAUNCH_TOKEN_SIZE);
+
+	if (copy_from_user(sigstruct, (void __user *)einit.sigstruct,
+			   sizeof(*sigstruct))) {
+		ret = -EFAULT;
+		goto out;
+	}
+
+	/*
+	 * A legacy field used with Intel signed enclaves. These used to mean
+	 * regular and architectural enclaves. The CPU only accepts these values
+	 * but they do not have any other meaning.
+	 *
+	 * Thus, reject any other values.
+	 */
+	if (sigstruct->header.vendor != 0x0000 &&
+	    sigstruct->header.vendor != 0x8086) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = sgx_encl_init(encl, sigstruct, token);
+
+out:
+	kunmap(initp_page);
+	__free_page(initp_page);
+	return ret;
+}
+
+
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 {
 	struct sgx_encl *encl = filep->private_data;
@@ -503,6 +695,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 	case SGX_IOC_ENCLAVE_ADD_PAGES:
 		ret = sgx_ioc_enclave_add_pages(encl, (void __user *)arg);
 		break;
+	case SGX_IOC_ENCLAVE_INIT:
+		ret = sgx_ioc_enclave_init(encl, (void __user *)arg);
+		break;
 	default:
 		ret = -ENOIOCTLCMD;
 		break;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (13 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-21 18:07   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
                   ` (8 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

Provisioning Certification Enclave (PCE), the root of trust for other
enclaves, generates a signing key from a fused key called Provisioning
Certification Key. PCE can then use this key to certify an attestation key
of a Quoting Enclave (QE), e.g. we get the chain of trust down to the
hardware if the Intel signed PCE is used.

To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be
only allowed for those who actually need it so that only the trusted
parties can certify QE's.

Obviously the attestation service should know the public key of the used
PCE and that way detect illegit attestation, but whitelisting the legit
users still adds an additional layer of defence.

Add new device file called /dev/sgx/provision. The sole purpose of this
file is to provide file descriptors that act as privilege tokens to allow
to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called
SGX_IOC_ENCLAVE_PROVISION is used to assign this token to an enclave.

Cc: linux-security-module@vger.kernel.org
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/uapi/asm/sgx.h  | 11 ++++++++
 arch/x86/kernel/cpu/sgx/driver.c | 18 ++++++++++++
 arch/x86/kernel/cpu/sgx/driver.h |  2 ++
 arch/x86/kernel/cpu/sgx/ioctl.c  | 47 ++++++++++++++++++++++++++++++++
 4 files changed, 78 insertions(+)

diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index 7729730d8580..d0916fb9629e 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -25,6 +25,8 @@ enum sgx_page_flags {
 	_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
 #define SGX_IOC_ENCLAVE_INIT \
 	_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_PROVISION \
+	_IOW(SGX_MAGIC, 0x03, struct sgx_enclave_provision)
 
 /**
  * struct sgx_enclave_create - parameter structure for the
@@ -61,4 +63,13 @@ struct sgx_enclave_init {
 	__u64 sigstruct;
 };
 
+/**
+ * struct sgx_enclave_provision - parameter structure for the
+ *				  %SGX_IOC_ENCLAVE_PROVISION ioctl
+ * @attribute_fd:	file handle of the attribute file in the securityfs
+ */
+struct sgx_enclave_provision {
+	__u64 attribute_fd;
+};
+
 #endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index 7bdb49dfcca6..d01b28f7ce4a 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -134,6 +134,10 @@ static const struct file_operations sgx_encl_fops = {
 	.get_unmapped_area	= sgx_get_unmapped_area,
 };
 
+const struct file_operations sgx_provision_fops = {
+	.owner			= THIS_MODULE,
+};
+
 static struct miscdevice sgx_dev_enclave = {
 	.minor = MISC_DYNAMIC_MINOR,
 	.name = "enclave",
@@ -141,6 +145,13 @@ static struct miscdevice sgx_dev_enclave = {
 	.fops = &sgx_encl_fops,
 };
 
+static struct miscdevice sgx_dev_provision = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "provision",
+	.nodename = "sgx/provision",
+	.fops = &sgx_provision_fops,
+};
+
 int __init sgx_drv_init(void)
 {
 	unsigned int eax, ebx, ecx, edx;
@@ -181,5 +192,12 @@ int __init sgx_drv_init(void)
 		return ret;
 	}
 
+	ret = misc_register(&sgx_dev_provision);
+	if (ret) {
+		pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
+		misc_deregister(&sgx_dev_enclave);
+		return ret;
+	}
+
 	return 0;
 }
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
index e4063923115b..72747d01c046 100644
--- a/arch/x86/kernel/cpu/sgx/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask;
 extern u64 sgx_xfrm_reserved_mask;
 extern u32 sgx_xsave_size_tbl[64];
 
+extern const struct file_operations sgx_provision_fops;
+
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
 
 int sgx_drv_init(void);
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index de2ed4f35ffb..4227bca7b477 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -673,6 +673,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
 	return ret;
 }
 
+/**
+ * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
+ * @filep:	open file to /dev/sgx
+ * @arg:	userspace pointer to a struct sgx_enclave_provision instance
+ *
+ * Mark the enclave as being allowed to access a restricted attribute bit.
+ * The requested attribute is specified via the attribute_fd field in the
+ * provided struct sgx_enclave_provision.  The attribute_fd must be a
+ * handle to an SGX attribute file, e.g. "/dev/sgx/provision".
+ *
+ * Failure to explicitly request access to a restricted attribute will cause
+ * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
+ * is access to the PROVISION_KEY.
+ *
+ * Note, access to the EINITTOKEN_KEY is disallowed entirely.
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+static long sgx_ioc_enclave_provision(struct sgx_encl *encl,
+					  void __user *arg)
+{
+	struct sgx_enclave_provision params;
+	struct file *attribute_file;
+	int ret;
+
+	if (copy_from_user(&params, arg, sizeof(params)))
+		return -EFAULT;
+
+	attribute_file = fget(params.attribute_fd);
+	if (!attribute_file)
+		return -EINVAL;
+
+	if (attribute_file->f_op != &sgx_provision_fops) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	encl->attributes |= SGX_ATTR_PROVISIONKEY;
+	ret = 0;
+
+out:
+	fput(attribute_file);
+	return ret;
+}
 
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 {
@@ -698,6 +742,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 	case SGX_IOC_ENCLAVE_INIT:
 		ret = sgx_ioc_enclave_init(encl, (void __user *)arg);
 		break;
+	case SGX_IOC_ENCLAVE_PROVISION:
+		ret = sgx_ioc_enclave_provision(encl, (void __user *)arg);
+		break;
 	default:
 		ret = -ENOIOCTLCMD;
 		break;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (14 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-22 10:45   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
                   ` (7 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, linux-mm, Jethro Beekman,
	Jordan Hand, Nathaniel McCallum, Chunyang Hui, Seth Moore,
	Sean Christopherson, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

There is a limited amount of EPC available. Therefore, some of it must be
copied to the regular memory, and only subset kept in the SGX reserved
memory. While kernel cannot directly access enclave memory, SGX provides a
set of ENCLS leaf functions to perform reclaiming.

This commits implements a page reclaimer by using these leaf functions. It
picks the victim pages in LRU fashion from all the enclaves running in the
system. The thread ksgxswapd reclaims pages on the event when the number of
free EPC pages goes below SGX_NR_LOW_PAGES up until it reaches
SGX_NR_HIGH_PAGES.

sgx_alloc_epc_page() can optionally directly reclaim pages with @reclaim
set true. A caller must also supply owner for each page so that the
reclaimer can access the associated enclaves. This is needed for locking,
as most of the ENCLS leafs cannot be executed concurrently for an enclave.
The owner is also needed for accessing SECS, which is required to be
resident when its child pages are being reclaimed.

Cc: linux-mm@kvack.org
Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
Tested-by: Seth Moore <sethmo@google.com>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/driver.c |   1 +
 arch/x86/kernel/cpu/sgx/encl.c   | 340 +++++++++++++++++++++-
 arch/x86/kernel/cpu/sgx/encl.h   |  41 +++
 arch/x86/kernel/cpu/sgx/ioctl.c  |  77 ++++-
 arch/x86/kernel/cpu/sgx/main.c   | 464 +++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/sgx.h    |   9 +
 6 files changed, 925 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index d01b28f7ce4a..0446781cc7a2 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -29,6 +29,7 @@ static int sgx_open(struct inode *inode, struct file *file)
 	atomic_set(&encl->flags, 0);
 	kref_init(&encl->refcount);
 	xa_init(&encl->page_array);
+	INIT_LIST_HEAD(&encl->va_pages);
 	mutex_init(&encl->lock);
 	INIT_LIST_HEAD(&encl->mm_list);
 	spin_lock_init(&encl->mm_lock);
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index c2c4a77af36b..11ec2df59b54 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -12,9 +12,84 @@
 #include "encls.h"
 #include "sgx.h"
 
+static int __sgx_encl_eldu(struct sgx_encl_page *encl_page,
+			   struct sgx_epc_page *epc_page,
+			   struct sgx_epc_page *secs_page)
+{
+	unsigned long va_offset = SGX_ENCL_PAGE_VA_OFFSET(encl_page);
+	struct sgx_encl *encl = encl_page->encl;
+	struct sgx_pageinfo pginfo;
+	struct sgx_backing b;
+	pgoff_t page_index;
+	int ret;
+
+	if (secs_page)
+		page_index = SGX_ENCL_PAGE_INDEX(encl_page);
+	else
+		page_index = PFN_DOWN(encl->size);
+
+	ret = sgx_encl_get_backing(encl, page_index, &b);
+	if (ret)
+		return ret;
+
+	pginfo.addr = SGX_ENCL_PAGE_ADDR(encl_page);
+	pginfo.contents = (unsigned long)kmap_atomic(b.contents);
+	pginfo.metadata = (unsigned long)kmap_atomic(b.pcmd) +
+			  b.pcmd_offset;
+
+	if (secs_page)
+		pginfo.secs = (u64)sgx_get_epc_addr(secs_page);
+	else
+		pginfo.secs = 0;
+
+	ret = __eldu(&pginfo, sgx_get_epc_addr(epc_page),
+		     sgx_get_epc_addr(encl_page->va_page->epc_page) +
+				      va_offset);
+	if (ret) {
+		if (encls_failed(ret))
+			ENCLS_WARN(ret, "ELDU");
+
+		ret = -EFAULT;
+	}
+
+	kunmap_atomic((void *)(unsigned long)(pginfo.metadata - b.pcmd_offset));
+	kunmap_atomic((void *)(unsigned long)pginfo.contents);
+
+	sgx_encl_put_backing(&b, false);
+
+	return ret;
+}
+
+static struct sgx_epc_page *sgx_encl_eldu(struct sgx_encl_page *encl_page,
+					  struct sgx_epc_page *secs_page)
+{
+	unsigned long va_offset = SGX_ENCL_PAGE_VA_OFFSET(encl_page);
+	struct sgx_encl *encl = encl_page->encl;
+	struct sgx_epc_page *epc_page;
+	int ret;
+
+	epc_page = sgx_alloc_epc_page(encl_page, false);
+	if (IS_ERR(epc_page))
+		return epc_page;
+
+	ret = __sgx_encl_eldu(encl_page, epc_page, secs_page);
+	if (ret) {
+		sgx_free_epc_page(epc_page);
+		return ERR_PTR(ret);
+	}
+
+	sgx_free_va_slot(encl_page->va_page, va_offset);
+	list_move(&encl_page->va_page->list, &encl->va_pages);
+	encl_page->desc &= ~SGX_ENCL_PAGE_VA_OFFSET_MASK;
+	encl_page->epc_page = epc_page;
+
+	return epc_page;
+}
+
 static struct sgx_encl_page *sgx_encl_load_page(struct sgx_encl *encl,
 						unsigned long addr)
 {
+	struct sgx_epc_page *epc_page;
 	struct sgx_encl_page *entry;
 	unsigned int flags;
 
@@ -33,10 +108,27 @@ static struct sgx_encl_page *sgx_encl_load_page(struct sgx_encl *encl,
 		return ERR_PTR(-EFAULT);
 
 	/* Page is already resident in the EPC. */
-	if (entry->epc_page)
+	if (entry->epc_page) {
+		if (entry->desc & SGX_ENCL_PAGE_RECLAIMED)
+			return ERR_PTR(-EBUSY);
+
 		return entry;
+	}
+
+	if (!(encl->secs.epc_page)) {
+		epc_page = sgx_encl_eldu(&encl->secs, NULL);
+		if (IS_ERR(epc_page))
+			return ERR_CAST(epc_page);
+	}
+
+	epc_page = sgx_encl_eldu(entry, encl->secs.epc_page);
+	if (IS_ERR(epc_page))
+		return ERR_CAST(epc_page);
 
-	return ERR_PTR(-EFAULT);
+	encl->secs_child_cnt++;
+	sgx_mark_page_reclaimable(entry->epc_page);
+
+	return entry;
 }
 
 static void sgx_mmu_notifier_release(struct mmu_notifier *mn,
@@ -132,6 +224,9 @@ int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm)
 
 	spin_lock(&encl->mm_lock);
 	list_add_rcu(&encl_mm->list, &encl->mm_list);
+	/* Pairs with smp_rmb() in sgx_reclaimer_block(). */
+	smp_wmb();
+	encl->mm_list_version++;
 	spin_unlock(&encl->mm_lock);
 
 	return 0;
@@ -179,6 +274,8 @@ static unsigned int sgx_vma_fault(struct vm_fault *vmf)
 		goto out;
 	}
 
+	sgx_encl_test_and_clear_young(vma->vm_mm, entry);
+
 out:
 	mutex_unlock(&encl->lock);
 	return ret;
@@ -280,6 +377,7 @@ int sgx_encl_find(struct mm_struct *mm, unsigned long addr,
  */
 void sgx_encl_destroy(struct sgx_encl *encl)
 {
+	struct sgx_va_page *va_page;
 	struct sgx_encl_page *entry;
 	unsigned long index;
 
@@ -287,6 +385,13 @@ void sgx_encl_destroy(struct sgx_encl *encl)
 
 	xa_for_each(&encl->page_array, index, entry) {
 		if (entry->epc_page) {
+			/*
+			 * The page and its radix tree entry cannot be freed
+			 * if the page is being held by the reclaimer.
+			 */
+			if (sgx_unmark_page_reclaimable(entry->epc_page))
+				continue;
+
 			sgx_free_epc_page(entry->epc_page);
 			encl->secs_child_cnt--;
 			entry->epc_page = NULL;
@@ -301,6 +406,19 @@ void sgx_encl_destroy(struct sgx_encl *encl)
 		sgx_free_epc_page(encl->secs.epc_page);
 		encl->secs.epc_page = NULL;
 	}
+
+	/*
+	 * The reclaimer is responsible for checking SGX_ENCL_DEAD before doing
+	 * EWB, thus it's safe to free VA pages even if the reclaimer holds a
+	 * reference to the enclave.
+	 */
+	while (!list_empty(&encl->va_pages)) {
+		va_page = list_first_entry(&encl->va_pages, struct sgx_va_page,
+					   list);
+		list_del(&va_page->list);
+		sgx_free_epc_page(va_page->epc_page);
+		kfree(va_page);
+	}
 }
 
 /**
@@ -329,3 +447,221 @@ void sgx_encl_release(struct kref *ref)
 
 	kfree(encl);
 }
+
+static struct page *sgx_encl_get_backing_page(struct sgx_encl *encl,
+					      pgoff_t index)
+{
+	struct inode *inode = encl->backing->f_path.dentry->d_inode;
+	struct address_space *mapping = inode->i_mapping;
+	gfp_t gfpmask = mapping_gfp_mask(mapping);
+
+	return shmem_read_mapping_page_gfp(mapping, index, gfpmask);
+}
+
+/**
+ * sgx_encl_get_backing() - Pin the backing storage
+ * @encl:	an enclave pointer
+ * @page_index:	enclave page index
+ * @backing:	data for accessing backing storage for the page
+ *
+ * Pin the backing storage pages for storing the encrypted contents and Paging
+ * Crypto MetaData (PCMD) of an enclave page.
+ *
+ * Return:
+ *   0 on success,
+ *   -errno otherwise.
+ */
+int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index,
+			 struct sgx_backing *backing)
+{
+	pgoff_t pcmd_index = PFN_DOWN(encl->size) + 1 + (page_index >> 5);
+	struct page *contents;
+	struct page *pcmd;
+
+	contents = sgx_encl_get_backing_page(encl, page_index);
+	if (IS_ERR(contents))
+		return PTR_ERR(contents);
+
+	pcmd = sgx_encl_get_backing_page(encl, pcmd_index);
+	if (IS_ERR(pcmd)) {
+		put_page(contents);
+		return PTR_ERR(pcmd);
+	}
+
+	backing->page_index = page_index;
+	backing->contents = contents;
+	backing->pcmd = pcmd;
+	backing->pcmd_offset =
+		(page_index & (PAGE_SIZE / sizeof(struct sgx_pcmd) - 1)) *
+		sizeof(struct sgx_pcmd);
+
+	return 0;
+}
+
+/**
+ * sgx_encl_put_backing() - Unpin the backing storage
+ * @backing:	data for accessing backing storage for the page
+ * @do_write:	mark pages dirty
+ */
+void sgx_encl_put_backing(struct sgx_backing *backing, bool do_write)
+{
+	if (do_write) {
+		set_page_dirty(backing->pcmd);
+		set_page_dirty(backing->contents);
+	}
+
+	put_page(backing->pcmd);
+	put_page(backing->contents);
+}
+
+static int sgx_encl_test_and_clear_young_cb(pte_t *ptep, unsigned long addr,
+					    void *data)
+{
+	pte_t pte;
+	int ret;
+
+	ret = pte_young(*ptep);
+	if (ret) {
+		pte = pte_mkold(*ptep);
+		set_pte_at((struct mm_struct *)data, addr, ptep, pte);
+	}
+
+	return ret;
+}
+
+/**
+ * sgx_encl_test_and_clear_young() - Test and reset the accessed bit
+ * @mm:		mm_struct that is checked
+ * @page:	enclave page to be tested for recent access
+ *
+ * Checks the Access (A) bit from the PTE corresponding to the enclave page and
+ * clears it.
+ *
+ * Return: 1 if the page has been recently accessed and 0 if not.
+ */
+int sgx_encl_test_and_clear_young(struct mm_struct *mm,
+				  struct sgx_encl_page *page)
+{
+	unsigned long addr = SGX_ENCL_PAGE_ADDR(page);
+	struct sgx_encl *encl = page->encl;
+	struct vm_area_struct *vma;
+	int ret;
+
+	ret = sgx_encl_find(mm, addr, &vma);
+	if (ret)
+		return 0;
+
+	if (encl != vma->vm_private_data)
+		return 0;
+
+	ret = apply_to_page_range(vma->vm_mm, addr, PAGE_SIZE,
+				  sgx_encl_test_and_clear_young_cb, vma->vm_mm);
+	if (ret < 0)
+		return 0;
+
+	return ret;
+}
+
+/**
+ * sgx_encl_reserve_page() - Reserve an enclave page
+ * @encl:	an enclave pointer
+ * @addr:	a page address
+ *
+ * Load an enclave page and lock the enclave so that the page can be used by
+ * EDBG* and EMOD*.
+ *
+ * Return:
+ *   an enclave page on success
+ *   -EFAULT	if the load fails
+ */
+struct sgx_encl_page *sgx_encl_reserve_page(struct sgx_encl *encl,
+					    unsigned long addr)
+{
+	struct sgx_encl_page *entry;
+
+	for ( ; ; ) {
+		mutex_lock(&encl->lock);
+
+		entry = sgx_encl_load_page(encl, addr);
+		if (PTR_ERR(entry) != -EBUSY)
+			break;
+
+		mutex_unlock(&encl->lock);
+	}
+
+	if (IS_ERR(entry))
+		mutex_unlock(&encl->lock);
+
+	return entry;
+}
+
+/**
+ * sgx_alloc_va_page() - Allocate a Version Array (VA) page
+ *
+ * Allocate a free EPC page and convert it to a Version Array (VA) page.
+ *
+ * Return:
+ *   a VA page,
+ *   -errno otherwise
+ */
+struct sgx_epc_page *sgx_alloc_va_page(void)
+{
+	struct sgx_epc_page *epc_page;
+	int ret;
+
+	epc_page = sgx_alloc_epc_page(NULL, true);
+	if (IS_ERR(epc_page))
+		return ERR_CAST(epc_page);
+
+	ret = __epa(sgx_get_epc_addr(epc_page));
+	if (ret) {
+		WARN_ONCE(1, "EPA returned %d (0x%x)", ret, ret);
+		sgx_free_epc_page(epc_page);
+		return ERR_PTR(-EFAULT);
+	}
+
+	return epc_page;
+}
+
+/**
+ * sgx_alloc_va_slot - allocate a VA slot
+ * @va_page:	a &struct sgx_va_page instance
+ *
+ * Allocates a slot from a &struct sgx_va_page instance.
+ *
+ * Return: offset of the slot inside the VA page
+ */
+unsigned int sgx_alloc_va_slot(struct sgx_va_page *va_page)
+{
+	int slot = find_first_zero_bit(va_page->slots, SGX_VA_SLOT_COUNT);
+
+	if (slot < SGX_VA_SLOT_COUNT)
+		set_bit(slot, va_page->slots);
+
+	return slot << 3;
+}
+
+/**
+ * sgx_free_va_slot - free a VA slot
+ * @va_page:	a &struct sgx_va_page instance
+ * @offset:	offset of the slot inside the VA page
+ *
+ * Frees a slot from a &struct sgx_va_page instance.
+ */
+void sgx_free_va_slot(struct sgx_va_page *va_page, unsigned int offset)
+{
+	clear_bit(offset >> 3, va_page->slots);
+}
+
+/**
+ * sgx_va_page_full - is the VA page full?
+ * @va_page:	a &struct sgx_va_page instance
+ *
+ * Return: true if all slots have been taken
+ */
+bool sgx_va_page_full(struct sgx_va_page *va_page)
+{
+	int slot = find_first_zero_bit(va_page->slots, SGX_VA_SLOT_COUNT);
+
+	return slot == SGX_VA_SLOT_COUNT;
+}
diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
index 0448d22d3010..11dcf4e7fb3e 100644
--- a/arch/x86/kernel/cpu/sgx/encl.h
+++ b/arch/x86/kernel/cpu/sgx/encl.h
@@ -19,6 +19,10 @@
 
 /**
  * enum sgx_encl_page_desc - defines bits for an enclave page's descriptor
+ * %SGX_ENCL_PAGE_RECLAIMED:		The page is in the process of being
+ *					reclaimed.
+ * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
+ *					(VA) page for a swapped page.
  * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
  *
  * The page address for SECS is zero and is used by the subsystem to recognize
@@ -26,16 +30,23 @@
  */
 enum sgx_encl_page_desc {
 	/* Bits 11:3 are available when the page is not swapped. */
+	SGX_ENCL_PAGE_RECLAIMED		= BIT(3),
+	SGX_ENCL_PAGE_VA_OFFSET_MASK	= GENMASK_ULL(11, 3),
 	SGX_ENCL_PAGE_ADDR_MASK		= PAGE_MASK,
 };
 
 #define SGX_ENCL_PAGE_ADDR(page) \
 	((page)->desc & SGX_ENCL_PAGE_ADDR_MASK)
+#define SGX_ENCL_PAGE_VA_OFFSET(page) \
+	((page)->desc & SGX_ENCL_PAGE_VA_OFFSET_MASK)
+#define SGX_ENCL_PAGE_INDEX(page) \
+	PFN_DOWN((page)->desc - (page)->encl->base)
 
 struct sgx_encl_page {
 	unsigned long desc;
 	unsigned long vm_max_prot_bits;
 	struct sgx_epc_page *epc_page;
+	struct sgx_va_page *va_page;
 	struct sgx_encl *encl;
 };
 
@@ -61,6 +72,7 @@ struct sgx_encl {
 	struct mutex lock;
 	struct list_head mm_list;
 	spinlock_t mm_lock;
+	unsigned long mm_list_version;
 	struct file *backing;
 	struct kref refcount;
 	struct srcu_struct srcu;
@@ -68,12 +80,21 @@ struct sgx_encl {
 	unsigned long size;
 	unsigned long ssaframesize;
 	struct xarray page_array;
+	struct list_head va_pages;
 	struct sgx_encl_page secs;
 	cpumask_t cpumask;
 	unsigned long attributes;
 	unsigned long attributes_mask;
 };
 
+#define SGX_VA_SLOT_COUNT 512
+
+struct sgx_va_page {
+	struct sgx_epc_page *epc_page;
+	DECLARE_BITMAP(slots, SGX_VA_SLOT_COUNT);
+	struct list_head list;
+};
+
 extern const struct vm_operations_struct sgx_vm_ops;
 
 int sgx_encl_find(struct mm_struct *mm, unsigned long addr,
@@ -84,4 +105,24 @@ int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm);
 int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
 		     unsigned long end, unsigned long vm_flags);
 
+struct sgx_backing {
+	pgoff_t page_index;
+	struct page *contents;
+	struct page *pcmd;
+	unsigned long pcmd_offset;
+};
+
+int sgx_encl_get_backing(struct sgx_encl *encl, unsigned long page_index,
+			 struct sgx_backing *backing);
+void sgx_encl_put_backing(struct sgx_backing *backing, bool do_write);
+int sgx_encl_test_and_clear_young(struct mm_struct *mm,
+				  struct sgx_encl_page *page);
+struct sgx_encl_page *sgx_encl_reserve_page(struct sgx_encl *encl,
+					    unsigned long addr);
+
+struct sgx_epc_page *sgx_alloc_va_page(void);
+unsigned int sgx_alloc_va_slot(struct sgx_va_page *va_page);
+void sgx_free_va_slot(struct sgx_va_page *va_page, unsigned int offset);
+bool sgx_va_page_full(struct sgx_va_page *va_page);
+
 #endif /* _X86_ENCL_H */
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 4227bca7b477..4264dc8c2a4f 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -19,6 +19,43 @@
 /* A per-cpu cache for the last known values of IA32_SGXLEPUBKEYHASHx MSRs. */
 static DEFINE_PER_CPU(u64 [4], sgx_lepubkeyhash_cache);
 
+static struct sgx_va_page *sgx_encl_grow(struct sgx_encl *encl)
+{
+	struct sgx_va_page *va_page = NULL;
+	void *err;
+
+	BUILD_BUG_ON(SGX_VA_SLOT_COUNT !=
+		(SGX_ENCL_PAGE_VA_OFFSET_MASK >> 3) + 1);
+
+	if (!(encl->page_cnt % SGX_VA_SLOT_COUNT)) {
+		va_page = kzalloc(sizeof(*va_page), GFP_KERNEL);
+		if (!va_page)
+			return ERR_PTR(-ENOMEM);
+
+		va_page->epc_page = sgx_alloc_va_page();
+		if (IS_ERR(va_page->epc_page)) {
+			err = ERR_CAST(va_page->epc_page);
+			kfree(va_page);
+			return err;
+		}
+
+		WARN_ON_ONCE(encl->page_cnt % SGX_VA_SLOT_COUNT);
+	}
+	encl->page_cnt++;
+	return va_page;
+}
+
+static void sgx_encl_shrink(struct sgx_encl *encl, struct sgx_va_page *va_page)
+{
+	encl->page_cnt--;
+
+	if (va_page) {
+		sgx_free_epc_page(va_page->epc_page);
+		list_del(&va_page->list);
+		kfree(va_page);
+	}
+}
+
 static u32 sgx_calc_ssa_frame_size(u32 miscselect, u64 xfrm)
 {
 	u32 size_max = PAGE_SIZE;
@@ -86,24 +123,34 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
 {
 	unsigned long encl_size = secs->size + PAGE_SIZE;
 	struct sgx_epc_page *secs_epc;
+	struct sgx_va_page *va_page;
 	struct sgx_pageinfo pginfo;
 	struct sgx_secinfo secinfo;
 	struct file *backing;
 	long ret;
 
+	va_page = sgx_encl_grow(encl);
+	if (IS_ERR(va_page))
+		return PTR_ERR(va_page);
+	else if (va_page)
+		list_add(&va_page->list, &encl->va_pages);
+
 	if (sgx_validate_secs(secs)) {
 		pr_debug("invalid SECS\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto err_out_shrink;
 	}
 
 	backing = shmem_file_setup("SGX backing", encl_size + (encl_size >> 5),
 				   VM_NORESERVE);
-	if (IS_ERR(backing))
-		return PTR_ERR(backing);
+	if (IS_ERR(backing)) {
+		ret = PTR_ERR(backing);
+		goto err_out_shrink;
+	}
 
 	encl->backing = backing;
 
-	secs_epc = __sgx_alloc_epc_page();
+	secs_epc = sgx_alloc_epc_page(&encl->secs, true);
 	if (IS_ERR(secs_epc)) {
 		ret = PTR_ERR(secs_epc);
 		goto err_out_backing;
@@ -151,6 +198,9 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
 	fput(encl->backing);
 	encl->backing = NULL;
 
+err_out_shrink:
+	sgx_encl_shrink(encl, va_page);
+
 	return ret;
 }
 
@@ -323,21 +373,35 @@ static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
 {
 	struct sgx_encl_page *encl_page;
 	struct sgx_epc_page *epc_page;
+	struct sgx_va_page *va_page;
 	int ret;
 
 	encl_page = sgx_encl_page_alloc(encl, offset, secinfo->flags);
 	if (IS_ERR(encl_page))
 		return PTR_ERR(encl_page);
 
-	epc_page = __sgx_alloc_epc_page();
+	epc_page = sgx_alloc_epc_page(encl_page, true);
 	if (IS_ERR(epc_page)) {
 		kfree(encl_page);
 		return PTR_ERR(epc_page);
 	}
 
+	va_page = sgx_encl_grow(encl);
+	if (IS_ERR(va_page)) {
+		ret = PTR_ERR(va_page);
+		goto err_out_free;
+	}
+
 	mmap_read_lock(current->mm);
 	mutex_lock(&encl->lock);
 
+	/*
+	 * Adding to encl->va_pages must be done under encl->lock.  Ditto for
+	 * deleting (via sgx_encl_shrink()) in the error path.
+	 */
+	if (va_page)
+		list_add(&va_page->list, &encl->va_pages);
+
 	/*
 	 * Insert prior to EADD in case of OOM.  EADD modifies MRENCLAVE, i.e.
 	 * can't be gracefully unwound, while failure on EADD/EXTEND is limited
@@ -368,6 +432,7 @@ static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
 			goto err_out;
 	}
 
+	sgx_mark_page_reclaimable(encl_page->epc_page);
 	mutex_unlock(&encl->lock);
 	mmap_read_unlock(current->mm);
 	return ret;
@@ -376,9 +441,11 @@ static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
 	xa_erase(&encl->page_array, PFN_DOWN(encl_page->desc));
 
 err_out_unlock:
+	sgx_encl_shrink(encl, va_page);
 	mutex_unlock(&encl->lock);
 	mmap_read_unlock(current->mm);
 
+err_out_free:
 	sgx_free_epc_page(epc_page);
 	kfree(encl_page);
 
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 4137254fb29e..3594d37d545f 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -16,6 +16,378 @@
 struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
 static int sgx_nr_epc_sections;
 static struct task_struct *ksgxswapd_tsk;
+static DECLARE_WAIT_QUEUE_HEAD(ksgxswapd_waitq);
+static LIST_HEAD(sgx_active_page_list);
+static DEFINE_SPINLOCK(sgx_active_page_list_lock);
+
+/**
+ * sgx_mark_page_reclaimable() - Mark a page as reclaimable
+ * @page:	EPC page
+ *
+ * Mark a page as reclaimable and add it to the active page list. Pages
+ * are automatically removed from the active list when freed.
+ */
+void sgx_mark_page_reclaimable(struct sgx_epc_page *page)
+{
+	spin_lock(&sgx_active_page_list_lock);
+	page->desc |= SGX_EPC_PAGE_RECLAIMABLE;
+	list_add_tail(&page->list, &sgx_active_page_list);
+	spin_unlock(&sgx_active_page_list_lock);
+}
+
+/**
+ * sgx_unmark_page_reclaimable() - Remove a page from the reclaim list
+ * @page:	EPC page
+ *
+ * Clear the reclaimable flag and remove the page from the active page list.
+ *
+ * Return:
+ *   0 on success,
+ *   -EBUSY if the page is in the process of being reclaimed
+ */
+int sgx_unmark_page_reclaimable(struct sgx_epc_page *page)
+{
+	/*
+	 * Remove the page from the active list if necessary.  If the page
+	 * is actively being reclaimed, i.e. RECLAIMABLE is set but the
+	 * page isn't on the active list, return -EBUSY as we can't free
+	 * the page at this time since it is "owned" by the reclaimer.
+	 */
+	spin_lock(&sgx_active_page_list_lock);
+	if (page->desc & SGX_EPC_PAGE_RECLAIMABLE) {
+		if (list_empty(&page->list)) {
+			spin_unlock(&sgx_active_page_list_lock);
+			return -EBUSY;
+		}
+		list_del(&page->list);
+		page->desc &= ~SGX_EPC_PAGE_RECLAIMABLE;
+	}
+	spin_unlock(&sgx_active_page_list_lock);
+
+	return 0;
+}
+
+static bool sgx_reclaimer_age(struct sgx_epc_page *epc_page)
+{
+	struct sgx_encl_page *page = epc_page->owner;
+	struct sgx_encl *encl = page->encl;
+	struct sgx_encl_mm *encl_mm;
+	bool ret = true;
+	int idx;
+
+	idx = srcu_read_lock(&encl->srcu);
+
+	list_for_each_entry_rcu(encl_mm, &encl->mm_list, list) {
+		if (!mmget_not_zero(encl_mm->mm))
+			continue;
+
+		mmap_read_lock(encl_mm->mm);
+		ret = !sgx_encl_test_and_clear_young(encl_mm->mm, page);
+		mmap_read_unlock(encl_mm->mm);
+
+		mmput_async(encl_mm->mm);
+
+		if (!ret || (atomic_read(&encl->flags) & SGX_ENCL_DEAD))
+			break;
+	}
+
+	srcu_read_unlock(&encl->srcu, idx);
+
+	if (!ret && !(atomic_read(&encl->flags) & SGX_ENCL_DEAD))
+		return false;
+
+	return true;
+}
+
+static void sgx_reclaimer_block(struct sgx_epc_page *epc_page)
+{
+	struct sgx_encl_page *page = epc_page->owner;
+	unsigned long addr = SGX_ENCL_PAGE_ADDR(page);
+	struct sgx_encl *encl = page->encl;
+	unsigned long mm_list_version;
+	struct sgx_encl_mm *encl_mm;
+	struct vm_area_struct *vma;
+	int idx, ret;
+
+	do {
+		mm_list_version = encl->mm_list_version;
+
+		/* Pairs with smp_rmb() in sgx_encl_mm_add(). */
+		smp_rmb();
+
+		idx = srcu_read_lock(&encl->srcu);
+
+		list_for_each_entry_rcu(encl_mm, &encl->mm_list, list) {
+			if (!mmget_not_zero(encl_mm->mm))
+				continue;
+
+			mmap_read_lock(encl_mm->mm);
+
+			ret = sgx_encl_find(encl_mm->mm, addr, &vma);
+			if (!ret && encl == vma->vm_private_data)
+				zap_vma_ptes(vma, addr, PAGE_SIZE);
+
+			mmap_read_unlock(encl_mm->mm);
+
+			mmput_async(encl_mm->mm);
+		}
+
+		srcu_read_unlock(&encl->srcu, idx);
+	} while (unlikely(encl->mm_list_version != mm_list_version));
+
+	mutex_lock(&encl->lock);
+
+	if (!(atomic_read(&encl->flags) & SGX_ENCL_DEAD)) {
+		ret = __eblock(sgx_get_epc_addr(epc_page));
+		if (encls_failed(ret))
+			ENCLS_WARN(ret, "EBLOCK");
+	}
+
+	mutex_unlock(&encl->lock);
+}
+
+static int __sgx_encl_ewb(struct sgx_epc_page *epc_page, void *va_slot,
+			  struct sgx_backing *backing)
+{
+	struct sgx_pageinfo pginfo;
+	int ret;
+
+	pginfo.addr = 0;
+	pginfo.secs = 0;
+
+	pginfo.contents = (unsigned long)kmap_atomic(backing->contents);
+	pginfo.metadata = (unsigned long)kmap_atomic(backing->pcmd) +
+			  backing->pcmd_offset;
+
+	ret = __ewb(&pginfo, sgx_get_epc_addr(epc_page), va_slot);
+
+	kunmap_atomic((void *)(unsigned long)(pginfo.metadata -
+					      backing->pcmd_offset));
+	kunmap_atomic((void *)(unsigned long)pginfo.contents);
+
+	return ret;
+}
+
+static void sgx_ipi_cb(void *info)
+{
+}
+
+static const cpumask_t *sgx_encl_ewb_cpumask(struct sgx_encl *encl)
+{
+	cpumask_t *cpumask = &encl->cpumask;
+	struct sgx_encl_mm *encl_mm;
+	int idx;
+
+	/*
+	 * Can race with sgx_encl_mm_add(), but ETRACK has already been
+	 * executed, which means that the CPUs running in the new mm will enter
+	 * into the enclave with a fresh epoch.
+	 */
+	cpumask_clear(cpumask);
+
+	idx = srcu_read_lock(&encl->srcu);
+
+	list_for_each_entry_rcu(encl_mm, &encl->mm_list, list) {
+		if (!mmget_not_zero(encl_mm->mm))
+			continue;
+
+		cpumask_or(cpumask, cpumask, mm_cpumask(encl_mm->mm));
+
+		mmput_async(encl_mm->mm);
+	}
+
+	srcu_read_unlock(&encl->srcu, idx);
+
+	return cpumask;
+}
+
+static void sgx_encl_ewb(struct sgx_epc_page *epc_page,
+			 struct sgx_backing *backing)
+{
+	struct sgx_encl_page *encl_page = epc_page->owner;
+	struct sgx_encl *encl = encl_page->encl;
+	struct sgx_va_page *va_page;
+	unsigned int va_offset;
+	void *va_slot;
+	int ret;
+
+	encl_page->desc &= ~SGX_ENCL_PAGE_RECLAIMED;
+
+	va_page = list_first_entry(&encl->va_pages, struct sgx_va_page,
+				   list);
+	va_offset = sgx_alloc_va_slot(va_page);
+	va_slot = sgx_get_epc_addr(va_page->epc_page) + va_offset;
+	if (sgx_va_page_full(va_page))
+		list_move_tail(&va_page->list, &encl->va_pages);
+
+	ret = __sgx_encl_ewb(epc_page, va_slot, backing);
+	if (ret == SGX_NOT_TRACKED) {
+		ret = __etrack(sgx_get_epc_addr(encl->secs.epc_page));
+		if (ret) {
+			if (encls_failed(ret))
+				ENCLS_WARN(ret, "ETRACK");
+		}
+
+		ret = __sgx_encl_ewb(epc_page, va_slot, backing);
+		if (ret == SGX_NOT_TRACKED) {
+			/*
+			 * Slow path, send IPIs to kick cpus out of the
+			 * enclave.  Note, it's imperative that the cpu
+			 * mask is generated *after* ETRACK, else we'll
+			 * miss cpus that entered the enclave between
+			 * generating the mask and incrementing epoch.
+			 */
+			on_each_cpu_mask(sgx_encl_ewb_cpumask(encl),
+					 sgx_ipi_cb, NULL, 1);
+			ret = __sgx_encl_ewb(epc_page, va_slot, backing);
+		}
+	}
+
+	if (ret) {
+		if (encls_failed(ret))
+			ENCLS_WARN(ret, "EWB");
+
+		sgx_free_va_slot(va_page, va_offset);
+	} else {
+		encl_page->desc |= va_offset;
+		encl_page->va_page = va_page;
+	}
+}
+
+static void sgx_reclaimer_write(struct sgx_epc_page *epc_page,
+				struct sgx_backing *backing)
+{
+	struct sgx_encl_page *encl_page = epc_page->owner;
+	struct sgx_encl *encl = encl_page->encl;
+	struct sgx_backing secs_backing;
+	int ret;
+
+	mutex_lock(&encl->lock);
+
+	if (atomic_read(&encl->flags) & SGX_ENCL_DEAD) {
+		ret = __eremove(sgx_get_epc_addr(epc_page));
+		ENCLS_WARN(ret, "EREMOVE");
+	} else {
+		sgx_encl_ewb(epc_page, backing);
+	}
+
+	encl_page->epc_page = NULL;
+	encl->secs_child_cnt--;
+
+	if (!encl->secs_child_cnt) {
+		if (atomic_read(&encl->flags) & SGX_ENCL_DEAD) {
+			sgx_free_epc_page(encl->secs.epc_page);
+			encl->secs.epc_page = NULL;
+		} else if (atomic_read(&encl->flags) & SGX_ENCL_INITIALIZED) {
+			ret = sgx_encl_get_backing(encl, PFN_DOWN(encl->size),
+						   &secs_backing);
+			if (ret)
+				goto out;
+
+			sgx_encl_ewb(encl->secs.epc_page, &secs_backing);
+
+			sgx_free_epc_page(encl->secs.epc_page);
+			encl->secs.epc_page = NULL;
+
+			sgx_encl_put_backing(&secs_backing, true);
+		}
+	}
+
+out:
+	mutex_unlock(&encl->lock);
+}
+
+/*
+ * Take a fixed number of pages from the head of the active page pool and
+ * reclaim them to the enclave's private shmem files. Skip the pages, which have
+ * been accessed since the last scan. Move those pages to the tail of active
+ * page pool so that the pages get scanned in LRU like fashion.
+ */
+static void sgx_reclaim_pages(void)
+{
+	struct sgx_epc_page *chunk[SGX_NR_TO_SCAN];
+	struct sgx_backing backing[SGX_NR_TO_SCAN];
+	struct sgx_epc_section *section;
+	struct sgx_encl_page *encl_page;
+	struct sgx_epc_page *epc_page;
+	int cnt = 0;
+	int ret;
+	int i;
+
+	spin_lock(&sgx_active_page_list_lock);
+	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
+		if (list_empty(&sgx_active_page_list))
+			break;
+
+		epc_page = list_first_entry(&sgx_active_page_list,
+					    struct sgx_epc_page, list);
+		list_del_init(&epc_page->list);
+		encl_page = epc_page->owner;
+
+		if (kref_get_unless_zero(&encl_page->encl->refcount) != 0)
+			chunk[cnt++] = epc_page;
+		else
+			/* The owner is freeing the page. No need to add the
+			 * page back to the list of reclaimable pages.
+			 */
+			epc_page->desc &= ~SGX_EPC_PAGE_RECLAIMABLE;
+	}
+	spin_unlock(&sgx_active_page_list_lock);
+
+	for (i = 0; i < cnt; i++) {
+		epc_page = chunk[i];
+		encl_page = epc_page->owner;
+
+		if (!sgx_reclaimer_age(epc_page))
+			goto skip;
+
+		ret = sgx_encl_get_backing(encl_page->encl,
+					   SGX_ENCL_PAGE_INDEX(encl_page),
+					   &backing[i]);
+		if (ret)
+			goto skip;
+
+		mutex_lock(&encl_page->encl->lock);
+		encl_page->desc |= SGX_ENCL_PAGE_RECLAIMED;
+		mutex_unlock(&encl_page->encl->lock);
+		continue;
+
+skip:
+		spin_lock(&sgx_active_page_list_lock);
+		list_add_tail(&epc_page->list, &sgx_active_page_list);
+		spin_unlock(&sgx_active_page_list_lock);
+
+		kref_put(&encl_page->encl->refcount, sgx_encl_release);
+
+		chunk[i] = NULL;
+	}
+
+	for (i = 0; i < cnt; i++) {
+		epc_page = chunk[i];
+		if (epc_page)
+			sgx_reclaimer_block(epc_page);
+	}
+
+	for (i = 0; i < cnt; i++) {
+		epc_page = chunk[i];
+		if (!epc_page)
+			continue;
+
+		encl_page = epc_page->owner;
+		sgx_reclaimer_write(epc_page, &backing[i]);
+		sgx_encl_put_backing(&backing[i], true);
+
+		kref_put(&encl_page->encl->refcount, sgx_encl_release);
+		epc_page->desc &= ~SGX_EPC_PAGE_RECLAIMABLE;
+
+		section = sgx_get_epc_section(epc_page);
+		spin_lock(&section->lock);
+		list_add_tail(&epc_page->list, &section->page_list);
+		section->free_cnt++;
+		spin_unlock(&section->lock);
+	}
+}
+
 
 static void sgx_sanitize_section(struct sgx_epc_section *section)
 {
@@ -44,6 +416,23 @@ static void sgx_sanitize_section(struct sgx_epc_section *section)
 	}
 }
 
+static unsigned long sgx_nr_free_pages(void)
+{
+	unsigned long cnt = 0;
+	int i;
+
+	for (i = 0; i < sgx_nr_epc_sections; i++)
+		cnt += sgx_epc_sections[i].free_cnt;
+
+	return cnt;
+}
+
+static bool sgx_should_reclaim(unsigned long watermark)
+{
+	return sgx_nr_free_pages() < watermark &&
+	       !list_empty(&sgx_active_page_list);
+}
+
 static int ksgxswapd(void *p)
 {
 	int i;
@@ -69,6 +458,20 @@ static int ksgxswapd(void *p)
 			WARN(1, "EPC section %d has unsanitized pages.\n", i);
 	}
 
+	while (!kthread_should_stop()) {
+		if (try_to_freeze())
+			continue;
+
+		wait_event_freezable(ksgxswapd_waitq,
+				     kthread_should_stop() ||
+				     sgx_should_reclaim(SGX_NR_HIGH_PAGES));
+
+		if (sgx_should_reclaim(SGX_NR_HIGH_PAGES))
+			sgx_reclaim_pages();
+
+		cond_resched();
+	}
+
 	return 0;
 }
 
@@ -94,6 +497,7 @@ static struct sgx_epc_page *__sgx_alloc_epc_page_from_section(struct sgx_epc_sec
 
 	page = list_first_entry(&section->page_list, struct sgx_epc_page, list);
 	list_del_init(&page->list);
+	section->free_cnt--;
 
 	return page;
 }
@@ -127,6 +531,57 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void)
 	return ERR_PTR(-ENOMEM);
 }
 
+/**
+ * sgx_alloc_epc_page() - Allocate an EPC page
+ * @owner:	the owner of the EPC page
+ * @reclaim:	reclaim pages if necessary
+ *
+ * Iterate through EPC sections and borrow a free EPC page to the caller. When a
+ * page is no longer needed it must be released with sgx_free_epc_page(). If
+ * @reclaim is set to true, directly reclaim pages when we are out of pages. No
+ * mm's can be locked when @reclaim is set to true.
+ *
+ * Finally, wake up ksgxswapd when the number of pages goes below the watermark
+ * before returning back to the caller.
+ *
+ * Return:
+ *   an EPC page,
+ *   -errno on error
+ */
+struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim)
+{
+	struct sgx_epc_page *entry;
+
+	for ( ; ; ) {
+		entry = __sgx_alloc_epc_page();
+		if (!IS_ERR(entry)) {
+			entry->owner = owner;
+			break;
+		}
+
+		if (list_empty(&sgx_active_page_list))
+			return ERR_PTR(-ENOMEM);
+
+		if (!reclaim) {
+			entry = ERR_PTR(-EBUSY);
+			break;
+		}
+
+		if (signal_pending(current)) {
+			entry = ERR_PTR(-ERESTARTSYS);
+			break;
+		}
+
+		sgx_reclaim_pages();
+		schedule();
+	}
+
+	if (sgx_should_reclaim(SGX_NR_LOW_PAGES))
+		wake_up(&ksgxswapd_waitq);
+
+	return entry;
+}
+
 /**
  * sgx_free_epc_page() - Free an EPC page
  * @page:	an EPC page
@@ -138,12 +593,20 @@ void sgx_free_epc_page(struct sgx_epc_page *page)
 	struct sgx_epc_section *section = sgx_get_epc_section(page);
 	int ret;
 
+	/*
+	 * Don't take sgx_active_page_list_lock when asserting the page isn't
+	 * reclaimable, missing a WARN in the very rare case is preferable to
+	 * unnecessarily taking a global lock in the common case.
+	 */
+	WARN_ON_ONCE(page->desc & SGX_EPC_PAGE_RECLAIMABLE);
+
 	ret = __eremove(sgx_get_epc_addr(page));
 	if (WARN_ONCE(ret, "EREMOVE returned %d (0x%x)", ret, ret))
 		return;
 
 	spin_lock(&section->lock);
 	list_add_tail(&page->list, &section->page_list);
+	section->free_cnt++;
 	spin_unlock(&section->lock);
 }
 
@@ -194,6 +657,7 @@ static bool __init sgx_setup_epc_section(u64 addr, u64 size,
 		list_add_tail(&page->list, &section->unsanitized_page_list);
 	}
 
+	section->free_cnt = nr_pages;
 	return true;
 
 err_out:
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index 8d126070db1e..ec4f7b338dbe 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -15,6 +15,7 @@
 
 struct sgx_epc_page {
 	unsigned long desc;
+	struct sgx_encl_page *owner;
 	struct list_head list;
 };
 
@@ -27,6 +28,7 @@ struct sgx_epc_page {
 struct sgx_epc_section {
 	unsigned long pa;
 	void *va;
+	unsigned long free_cnt;
 	struct list_head page_list;
 	struct list_head unsanitized_page_list;
 	spinlock_t lock;
@@ -35,6 +37,10 @@ struct sgx_epc_section {
 #define SGX_EPC_SECTION_MASK		GENMASK(7, 0)
 #define SGX_MAX_EPC_SECTIONS		(SGX_EPC_SECTION_MASK + 1)
 #define SGX_MAX_ADD_PAGES_LENGTH	0x100000
+#define SGX_EPC_PAGE_RECLAIMABLE	BIT(8)
+#define SGX_NR_TO_SCAN			16
+#define SGX_NR_LOW_PAGES		32
+#define SGX_NR_HIGH_PAGES		64
 
 extern struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
 
@@ -50,7 +56,10 @@ static inline void *sgx_get_epc_addr(struct sgx_epc_page *page)
 	return section->va + (page->desc & PAGE_MASK) - section->pa;
 }
 
+void sgx_mark_page_reclaimable(struct sgx_epc_page *page);
+int sgx_unmark_page_reclaimable(struct sgx_epc_page *page);
 struct sgx_epc_page *__sgx_alloc_epc_page(void);
+struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim);
 void sgx_free_epc_page(struct sgx_epc_page *page);
 
 #endif /* _X86_SGX_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (15 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-22 15:44   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
                   ` (6 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

Add VMA callbacks for ptrace() that can be used with debug enclaves.
With debug enclaves data can be read and write the memory word at a time
by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/cpu/sgx/encl.c | 87 ++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 11ec2df59b54..7f8df2c8ef35 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -333,10 +333,97 @@ static int sgx_vma_mprotect(struct vm_area_struct *vma,
 	return mprotect_fixup(vma, pprev, start, end, newflags);
 }
 
+static int sgx_edbgrd(struct sgx_encl *encl, struct sgx_encl_page *page,
+		      unsigned long addr, void *data)
+{
+	unsigned long offset = addr & ~PAGE_MASK;
+	int ret;
+
+
+	ret = __edbgrd(sgx_get_epc_addr(page->epc_page) + offset, data);
+	if (ret)
+		return -EIO;
+
+	return 0;
+}
+
+static int sgx_edbgwr(struct sgx_encl *encl, struct sgx_encl_page *page,
+		      unsigned long addr, void *data)
+{
+	unsigned long offset = addr & ~PAGE_MASK;
+	int ret;
+
+	ret = __edbgwr(sgx_get_epc_addr(page->epc_page) + offset, data);
+	if (ret)
+		return -EIO;
+
+	return 0;
+}
+
+static int sgx_vma_access(struct vm_area_struct *vma, unsigned long addr,
+			  void *buf, int len, int write)
+{
+	struct sgx_encl *encl = vma->vm_private_data;
+	struct sgx_encl_page *entry = NULL;
+	char data[sizeof(unsigned long)];
+	unsigned long align;
+	unsigned int flags;
+	int offset;
+	int cnt;
+	int ret = 0;
+	int i;
+
+	/* If process was forked, VMA is still there but vm_private_data is set
+	 * to NULL.
+	 */
+	if (!encl)
+		return -EFAULT;
+
+	flags = atomic_read(&encl->flags);
+
+	if (!(flags & SGX_ENCL_DEBUG) || !(flags & SGX_ENCL_INITIALIZED) ||
+	    (flags & SGX_ENCL_DEAD))
+		return -EFAULT;
+
+	for (i = 0; i < len; i += cnt) {
+		entry = sgx_encl_reserve_page(encl, (addr + i) & PAGE_MASK);
+		if (IS_ERR(entry)) {
+			ret = PTR_ERR(entry);
+			break;
+		}
+
+		align = ALIGN_DOWN(addr + i, sizeof(unsigned long));
+		offset = (addr + i) & (sizeof(unsigned long) - 1);
+		cnt = sizeof(unsigned long) - offset;
+		cnt = min(cnt, len - i);
+
+		ret = sgx_edbgrd(encl, entry, align, data);
+		if (ret)
+			goto out;
+
+		if (write) {
+			memcpy(data + offset, buf + i, cnt);
+			ret = sgx_edbgwr(encl, entry, align, data);
+			if (ret)
+				goto out;
+		} else
+			memcpy(buf + i, data + offset, cnt);
+
+out:
+		mutex_unlock(&encl->lock);
+
+		if (ret)
+			break;
+	}
+
+	return ret < 0 ? ret : i;
+}
+
 const struct vm_operations_struct sgx_vm_ops = {
 	.open = sgx_vma_open,
 	.fault = sgx_vma_fault,
 	.mprotect = sgx_vma_mprotect,
+	.access = sgx_vma_access,
 };
 
 /**
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (16 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-23 22:07   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 19/24] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
                   ` (5 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Jarkko Sakkinen, akpm, andriy.shevchenko, asapek,
	bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

The basic concept and implementation is very similar to the kernel's
exception fixup mechanism.  The key differences are that the kernel
handler is hardcoded and the fixup entry addresses are relative to
the overall table as opposed to individual entries.

Hardcoding the kernel handler avoids the need to figure out how to
get userspace code to point at a kernel function.  Given that the
expected usage is to propagate information to userspace, dumping all
fault information into registers is likely the desired behavior for
the vast majority of yet-to-be-created functions.  Use registers
DI, SI and DX to communicate fault information, which follows Linux's
ABI for register consumption and hopefully avoids conflict with
hardware features that might leverage the fixup capabilities, e.g.
register usage for SGX instructions was at least partially designed
with calling conventions in mind.

Making fixup addresses relative to the overall table allows the table
to be stripped from the final vDSO image (it's a kernel construct)
without complicating the offset logic, e.g. entry-relative addressing
would also need to account for the table's location relative to the
image.

Regarding stripping the table, modify vdso2c to extract the table from
the raw, a.k.a. unstripped, data and dump it as a standalone byte array
in the resulting .c file.  The original base of the table, its length
and a pointer to the byte array are captured in struct vdso_image.
Alternatively, the table could be dumped directly into the struct,
but because the number of entries can vary per image, that would
require either hardcoding a max sized table into the struct definition
or defining the table as a flexible length array.  The flexible length
array approach has zero benefits, e.g. the base/size are still needed,
and prevents reusing the extraction code, while hardcoding the max size
adds ongoing maintenance just to avoid exporting the explicit size.

The immediate use case is for Intel Software Guard Extensions (SGX).
SGX introduces a new CPL3-only "enclave" mode that runs as a sort of
black box shared object that is hosted by an untrusted "normal" CPl3
process.

Entering an enclave can only be done through SGX-specific instructions,
EENTER and ERESUME, and is a non-trivial process.  Because of the
complexity of transitioning to/from an enclave, the vast majority of
enclaves are expected to utilize a library to handle the actual
transitions.  This is roughly analogous to how e.g. libc implementations
are used by most applications.

Another crucial characteristic of SGX enclaves is that they can generate
exceptions as part of their normal (at least as "normal" as SGX can be)
operation that need to be handled *in* the enclave and/or are unique
to SGX.

And because they are essentially fancy shared objects, a process can
host any number of enclaves, each of which can execute multiple threads
simultaneously.

Putting everything together, userspace enclaves will utilize a library
that must be prepared to handle any and (almost) all exceptions any time
at least one thread may be executing in an enclave.  Leveraging signals
to handle the enclave exceptions is unpleasant, to put it mildly, e.g.
the SGX library must constantly (un)register its signal handler based
on whether or not at least one thread is executing in an enclave, and
filter and forward exceptions that aren't related to its enclaves.  This
becomes particularly nasty when using multiple levels of libraries that
register signal handlers, e.g. running an enclave via cgo inside of the
Go runtime.

Enabling exception fixup in vDSO allows the kernel to provide a vDSO
function that wraps the low-level transitions to/from the enclave, i.e.
the EENTER and ERESUME instructions.  The vDSO function can intercept
exceptions that would otherwise generate a signal and return the fault
information directly to its caller, thus avoiding the need to juggle
signal handlers.

Note that unlike the kernel's _ASM_EXTABLE_HANDLE implementation, the
'C' version of _ASM_VDSO_EXTABLE_HANDLE doesn't use a pre-compiled
assembly macro.  Duplicating four lines of code is simpler than adding
the necessary infrastructure to generate pre-compiled assembly and the
intended benefit of massaging GCC's inlining algorithm is unlikely to
realized in the vDSO any time soon, if ever.

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/entry/vdso/Makefile          |  6 ++--
 arch/x86/entry/vdso/extable.c         | 46 ++++++++++++++++++++++++
 arch/x86/entry/vdso/extable.h         | 29 ++++++++++++++++
 arch/x86/entry/vdso/vdso-layout.lds.S |  9 ++++-
 arch/x86/entry/vdso/vdso2c.h          | 50 ++++++++++++++++++++++++++-
 arch/x86/include/asm/vdso.h           |  5 +++
 6 files changed, 140 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/entry/vdso/extable.c
 create mode 100644 arch/x86/entry/vdso/extable.h

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 215376d975a2..3f183d0b8826 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -31,7 +31,7 @@ vobjs32-y := vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
 vobjs32-y += vdso32/vclock_gettime.o
 
 # files to link into kernel
-obj-y				+= vma.o
+obj-y				+= vma.o extable.o
 KASAN_SANITIZE_vma.o		:= y
 UBSAN_SANITIZE_vma.o		:= y
 KCSAN_SANITIZE_vma.o		:= y
@@ -130,8 +130,8 @@ $(obj)/%-x32.o: $(obj)/%.o FORCE
 
 targets += vdsox32.lds $(vobjx32s-y)
 
-$(obj)/%.so: OBJCOPYFLAGS := -S
-$(obj)/%.so: $(obj)/%.so.dbg FORCE
+$(obj)/%.so: OBJCOPYFLAGS := -S --remove-section __ex_table
+$(obj)/%.so: $(obj)/%.so.dbg
 	$(call if_changed,objcopy)
 
 $(obj)/vdsox32.so.dbg: $(obj)/vdsox32.lds $(vobjx32s) FORCE
diff --git a/arch/x86/entry/vdso/extable.c b/arch/x86/entry/vdso/extable.c
new file mode 100644
index 000000000000..afcf5b65beef
--- /dev/null
+++ b/arch/x86/entry/vdso/extable.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/err.h>
+#include <linux/mm.h>
+#include <asm/current.h>
+#include <asm/traps.h>
+#include <asm/vdso.h>
+
+struct vdso_exception_table_entry {
+	int insn, fixup;
+};
+
+bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
+			  unsigned long error_code, unsigned long fault_addr)
+{
+	const struct vdso_image *image = current->mm->context.vdso_image;
+	const struct vdso_exception_table_entry *extable;
+	unsigned int nr_entries, i;
+	unsigned long base;
+
+	/*
+	 * Do not attempt to fixup #DB or #BP.  It's impossible to identify
+	 * whether or not a #DB/#BP originated from within an SGX enclave and
+	 * SGX enclaves are currently the only use case for vDSO fixup.
+	 */
+	if (trapnr == X86_TRAP_DB || trapnr == X86_TRAP_BP)
+		return false;
+
+	if (!current->mm->context.vdso)
+		return false;
+
+	base =  (unsigned long)current->mm->context.vdso + image->extable_base;
+	nr_entries = image->extable_len / (sizeof(*extable));
+	extable = image->extable;
+
+	for (i = 0; i < nr_entries; i++) {
+		if (regs->ip == base + extable[i].insn) {
+			regs->ip = base + extable[i].fixup;
+			regs->di = trapnr;
+			regs->si = error_code;
+			regs->dx = fault_addr;
+			return true;
+		}
+	}
+
+	return false;
+}
diff --git a/arch/x86/entry/vdso/extable.h b/arch/x86/entry/vdso/extable.h
new file mode 100644
index 000000000000..aafdac396948
--- /dev/null
+++ b/arch/x86/entry/vdso/extable.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __VDSO_EXTABLE_H
+#define __VDSO_EXTABLE_H
+
+/*
+ * Inject exception fixup for vDSO code.  Unlike normal exception fixup,
+ * vDSO uses a dedicated handler the addresses are relative to the overall
+ * exception table, not each individual entry.
+ */
+#ifdef __ASSEMBLY__
+#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
+	ASM_VDSO_EXTABLE_HANDLE from to
+
+.macro ASM_VDSO_EXTABLE_HANDLE from:req to:req
+	.pushsection __ex_table, "a"
+	.long (\from) - __ex_table
+	.long (\to) - __ex_table
+	.popsection
+.endm
+#else
+#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
+	".pushsection __ex_table, \"a\"\n"      \
+	".long (" #from ") - __ex_table\n"      \
+	".long (" #to ") - __ex_table\n"        \
+	".popsection\n"
+#endif
+
+#endif /* __VDSO_EXTABLE_H */
+
diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S b/arch/x86/entry/vdso/vdso-layout.lds.S
index 4d152933547d..dc8da7695859 100644
--- a/arch/x86/entry/vdso/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/vdso-layout.lds.S
@@ -75,11 +75,18 @@ SECTIONS
 	 * stuff that isn't used at runtime in between.
 	 */
 
-	.text		: { *(.text*) }			:text	=0x90909090,
+	.text		: {
+		*(.text*)
+		*(.fixup)
+	}						:text	=0x90909090,
+
+
 
 	.altinstructions	: { *(.altinstructions) }	:text
 	.altinstr_replacement	: { *(.altinstr_replacement) }	:text
 
+	__ex_table		: { *(__ex_table) }		:text
+
 	/DISCARD/ : {
 		*(.discard)
 		*(.discard.*)
diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
index 6f46e11ce539..1c7cfac7e64a 100644
--- a/arch/x86/entry/vdso/vdso2c.h
+++ b/arch/x86/entry/vdso/vdso2c.h
@@ -5,6 +5,41 @@
  * are built for 32-bit userspace.
  */
 
+static void BITSFUNC(copy)(FILE *outfile, const unsigned char *data, size_t len)
+{
+	size_t i;
+
+	for (i = 0; i < len; i++) {
+		if (i % 10 == 0)
+			fprintf(outfile, "\n\t");
+		fprintf(outfile, "0x%02X, ", (int)(data)[i]);
+	}
+}
+
+
+/*
+ * Extract a section from the input data into a standalone blob.  Used to
+ * capture kernel-only data that needs to persist indefinitely, e.g. the
+ * exception fixup tables, but only in the kernel, i.e. the section can
+ * be stripped from the final vDSO image.
+ */
+static void BITSFUNC(extract)(const unsigned char *data, size_t data_len,
+			      FILE *outfile, ELF(Shdr) *sec, const char *name)
+{
+	unsigned long offset;
+	size_t len;
+
+	offset = (unsigned long)GET_LE(&sec->sh_offset);
+	len = (size_t)GET_LE(&sec->sh_size);
+
+	if (offset + len > data_len)
+		fail("section to extract overruns input data");
+
+	fprintf(outfile, "static const unsigned char %s[%lu] = {", name, len);
+	BITSFUNC(copy)(outfile, data + offset, len);
+	fprintf(outfile, "\n};\n\n");
+}
+
 static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 			 void *stripped_addr, size_t stripped_len,
 			 FILE *outfile, const char *image_name)
@@ -15,7 +50,7 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 	ELF(Ehdr) *hdr = (ELF(Ehdr) *)raw_addr;
 	unsigned long i, syms_nr;
 	ELF(Shdr) *symtab_hdr = NULL, *strtab_hdr, *secstrings_hdr,
-		*alt_sec = NULL;
+		*alt_sec = NULL, *extable_sec = NULL;
 	ELF(Dyn) *dyn = 0, *dyn_end = 0;
 	const char *secstrings;
 	INT_BITS syms[NSYMS] = {};
@@ -77,6 +112,8 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 		if (!strcmp(secstrings + GET_LE(&sh->sh_name),
 			    ".altinstructions"))
 			alt_sec = sh;
+		if (!strcmp(secstrings + GET_LE(&sh->sh_name), "__ex_table"))
+			extable_sec = sh;
 	}
 
 	if (!symtab_hdr)
@@ -155,6 +192,9 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 			(int)((unsigned char *)stripped_addr)[i]);
 	}
 	fprintf(outfile, "\n};\n\n");
+	if (extable_sec)
+		BITSFUNC(extract)(raw_addr, raw_len, outfile,
+				  extable_sec, "extable");
 
 	fprintf(outfile, "const struct vdso_image %s = {\n", image_name);
 	fprintf(outfile, "\t.data = raw_data,\n");
@@ -165,6 +205,14 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 		fprintf(outfile, "\t.alt_len = %lu,\n",
 			(unsigned long)GET_LE(&alt_sec->sh_size));
 	}
+	if (extable_sec) {
+		fprintf(outfile, "\t.extable_base = %lu,\n",
+			(unsigned long)GET_LE(&extable_sec->sh_offset));
+		fprintf(outfile, "\t.extable_len = %lu,\n",
+			(unsigned long)GET_LE(&extable_sec->sh_size));
+		fprintf(outfile, "\t.extable = extable,\n");
+	}
+
 	for (i = 0; i < NSYMS; i++) {
 		if (required_syms[i].export && syms[i])
 			fprintf(outfile, "\t.sym_%s = %" PRIi64 ",\n",
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index bbcdc7b8f963..b5d23470f56b 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -15,6 +15,8 @@ struct vdso_image {
 	unsigned long size;   /* Always a multiple of PAGE_SIZE */
 
 	unsigned long alt, alt_len;
+	unsigned long extable_base, extable_len;
+	const void *extable;
 
 	long sym_vvar_start;  /* Negative offset to the vvar area */
 
@@ -45,6 +47,9 @@ extern void __init init_vdso_image(const struct vdso_image *image);
 
 extern int map_vdso_once(const struct vdso_image *image, unsigned long addr);
 
+extern bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
+				 unsigned long error_code,
+				 unsigned long fault_addr);
 #endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_VDSO_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 19/24] x86/fault: Add helper function to sanitize error code
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (17 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
                   ` (4 subsequent siblings)
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Jethro Beekman,
	Jarkko Sakkinen, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

Add helper function to sanitize error code to prepare for vDSO exception
fixup, which will expose the error code to userspace and runs before
set_signal_archinfo(), i.e. suppresses the signal when fixup is successful.

Acked-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/mm/fault.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 1a7cc6d3281a..9e5ec861aba0 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -555,6 +555,18 @@ pgtable_bad(struct pt_regs *regs, unsigned long error_code,
 	oops_end(flags, regs, sig);
 }
 
+static void sanitize_error_code(unsigned long address,
+				unsigned long *error_code)
+{
+	/*
+	 * To avoid leaking information about the kernel page
+	 * table layout, pretend that user-mode accesses to
+	 * kernel addresses are always protection faults.
+	 */
+	if (address >= TASK_SIZE_MAX)
+		*error_code |= X86_PF_PROT;
+}
+
 static void set_signal_archinfo(unsigned long address,
 				unsigned long error_code)
 {
@@ -611,6 +623,8 @@ no_context(struct pt_regs *regs, unsigned long error_code,
 		 * faulting through the emulate_vsyscall() logic.
 		 */
 		if (current->thread.sig_on_uaccess_err && signal) {
+			sanitize_error_code(address, &error_code);
+
 			set_signal_archinfo(address, error_code);
 
 			/* XXX: hwpoison faults will set the wrong code. */
@@ -759,13 +773,7 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
 		if (is_errata100(regs, address))
 			return;
 
-		/*
-		 * To avoid leaking information about the kernel page table
-		 * layout, pretend that user-mode accesses to kernel addresses
-		 * are always protection faults.
-		 */
-		if (address >= TASK_SIZE_MAX)
-			error_code |= X86_PF_PROT;
+		sanitize_error_code(address, &error_code);
 
 		if (likely(show_unhandled_signals))
 			show_signal_msg(regs, error_code, address, tsk);
@@ -884,6 +892,8 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
 	if (is_prefetch(regs, error_code, address))
 		return;
 
+	sanitize_error_code(address, &error_code);
+
 	set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (18 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 19/24] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-24 16:31   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
                   ` (3 subsequent siblings)
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Jarkko Sakkinen, akpm, andriy.shevchenko, asapek,
	bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup.  For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal.  This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.

Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information.  Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.

Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal.  Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/kernel/traps.c | 19 ++++++++++++++++---
 arch/x86/mm/fault.c     |  8 ++++++++
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 1f66d2d1e998..20a881485b6b 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
 #include <asm/umip.h>
 #include <asm/insn.h>
 #include <asm/insn-eval.h>
+#include <asm/vdso.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
@@ -116,6 +117,9 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
 		tsk->thread.error_code = error_code;
 		tsk->thread.trap_nr = trapnr;
 		die(str, regs, error_code);
+	} else {
+		if (fixup_vdso_exception(regs, trapnr, error_code, 0))
+			return 0;
 	}
 
 	/*
@@ -549,6 +553,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
 		tsk->thread.error_code = error_code;
 		tsk->thread.trap_nr = X86_TRAP_GP;
 
+		if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
+			return;
+
 		show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
 		force_sig(SIGSEGV);
 		goto exit;
@@ -827,9 +834,12 @@ static void handle_debug(struct pt_regs *regs, unsigned long dr6, bool user)
 #endif
 
 	if (notify_die(DIE_DEBUG, "debug", regs, (long)&dr6, 0,
-		       SIGTRAP) == NOTIFY_STOP) {
-		return;
-	}
+		       SIGTRAP) == NOTIFY_STOP)
+		goto out;
+
+	if (user_mode(regs) &&
+	    fixup_vdso_exception(regs, X86_TRAP_DB, 0, 0))
+		goto out;
 
 	/* It's safe to allow irq's after DR6 has been saved */
 	cond_local_irq_enable(regs);
@@ -981,6 +991,9 @@ static void math_error(struct pt_regs *regs, int trapnr)
 	if (!si_code)
 		goto exit;
 
+	if (fixup_vdso_exception(regs, trapnr, 0, 0))
+		return;
+
 	force_sig_fault(SIGFPE, si_code,
 			(void __user *)uprobe_get_trap_addr(regs));
 exit:
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9e5ec861aba0..ebe290a68c36 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -30,6 +30,7 @@
 #include <asm/cpu_entry_area.h>		/* exception stack		*/
 #include <asm/pgtable_areas.h>		/* VMALLOC_START, ...		*/
 #include <asm/kvm_para.h>		/* kvm_handle_async_pf		*/
+#include <asm/vdso.h>			/* fixup_vdso_exception()	*/
 
 #define CREATE_TRACE_POINTS
 #include <asm/trace/exceptions.h>
@@ -775,6 +776,10 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
 
 		sanitize_error_code(address, &error_code);
 
+		if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code,
+		    address))
+			return;
+
 		if (likely(show_unhandled_signals))
 			show_signal_msg(regs, error_code, address, tsk);
 
@@ -894,6 +899,9 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
 
 	sanitize_error_code(address, &error_code);
 
+	if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code, address))
+		return;
+
 	set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (19 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-24 18:04   ` Borislav Petkov
  2020-09-25 18:23   ` Andrew Cooper
  2020-09-15 11:28 ` [PATCH v38 22/24] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
                   ` (2 subsequent siblings)
  23 siblings, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, Jarkko Sakkinen, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

An SGX runtime must be aware of the exceptions, which happen inside an
enclave. Introduce a vDSO call that wraps EENTER/ERESUME cycle and returns
the CPU exception back to the caller exactly when it happens.

Kernel fixups the exception information to RDI, RSI and RDX. The SGX call
vDSO handler fills this information to the user provided buffer or
alternatively trigger user provided callback at the time of the exception.

The calling convention is custom and does not follow System V x86-64 ABI.

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Cedric Xing <cedric.xing@intel.com>
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/entry/vdso/Makefile             |   2 +
 arch/x86/entry/vdso/vdso.lds.S           |   1 +
 arch/x86/entry/vdso/vsgx_enter_enclave.S | 157 +++++++++++++++++++++++
 arch/x86/include/asm/enclu.h             |   8 ++
 arch/x86/include/uapi/asm/sgx.h          | 128 ++++++++++++++++++
 5 files changed, 296 insertions(+)
 create mode 100644 arch/x86/entry/vdso/vsgx_enter_enclave.S
 create mode 100644 arch/x86/include/asm/enclu.h

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 3f183d0b8826..416f9432269d 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -29,6 +29,7 @@ VDSO32-$(CONFIG_IA32_EMULATION)	:= y
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
 vobjs32-y := vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
 vobjs32-y += vdso32/vclock_gettime.o
+vobjs-$(VDSO64-y)		+= vsgx_enter_enclave.o
 
 # files to link into kernel
 obj-y				+= vma.o extable.o
@@ -100,6 +101,7 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS
 CFLAGS_REMOVE_vclock_gettime.o = -pg
 CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg
 CFLAGS_REMOVE_vgetcpu.o = -pg
+CFLAGS_REMOVE_vsgx_enter_enclave.o = -pg
 
 #
 # X32 processes use x32 vDSO to access 64bit kernel data.
diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
index 36b644e16272..4bf48462fca7 100644
--- a/arch/x86/entry/vdso/vdso.lds.S
+++ b/arch/x86/entry/vdso/vdso.lds.S
@@ -27,6 +27,7 @@ VERSION {
 		__vdso_time;
 		clock_getres;
 		__vdso_clock_getres;
+		__vdso_sgx_enter_enclave;
 	local: *;
 	};
 }
diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
new file mode 100644
index 000000000000..adbd59d41517
--- /dev/null
+++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <linux/linkage.h>
+#include <asm/export.h>
+#include <asm/errno.h>
+#include <asm/enclu.h>
+
+#include "extable.h"
+
+/* Offset of 'struct sgx_enclave_run' relative to %rbp. */
+#define SGX_ENCLAVE_RUN_PTR	2*8
+
+/* Offsets into 'struct sgx_enclave_run'. */
+#define SGX_ENCLAVE_RUN_TSC		0*8
+#define SGX_ENCLAVE_RUN_FLAGS		1*8
+#define SGX_ENCLAVE_RUN_EXIT_REASON	1*8 + 4
+#define SGX_ENCLAVE_RUN_USER_HANDLER	2*8
+/* #define SGX_ENCLAVE_RUN_USER_DATA	3*8 */
+#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
+
+#define SGX_SYNCHRONOUS_EXIT		0
+#define SGX_EXCEPTION_EXIT		1
+
+/* Offsets into sgx_enter_enclave.exception. */
+#define SGX_EX_LEAF			0*8
+#define SGX_EX_TRAPNR			0*8+4
+#define SGX_EX_ERROR_CODE		0*8+6
+#define SGX_EX_ADDRESS			1*8
+
+.code64
+.section .text, "ax"
+
+SYM_FUNC_START(__vdso_sgx_enter_enclave)
+	/* Prolog */
+	.cfi_startproc
+	push	%rbp
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%rbp, 0
+	mov	%rsp, %rbp
+	.cfi_def_cfa_register	%rbp
+	push	%rbx
+	.cfi_rel_offset		%rbx, -8
+
+	mov	%ecx, %eax
+.Lenter_enclave:
+	/* EENTER <= leaf <= ERESUME */
+	cmp	$EENTER, %eax
+	jb	.Linvalid_input
+	cmp	$ERESUME, %eax
+	ja	.Linvalid_input
+
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rcx
+
+	/* No flags are currently defined/supported. */
+	cmpl	$0, SGX_ENCLAVE_RUN_FLAGS(%rcx)
+	jne	.Linvalid_input
+
+	/* Load TCS and AEP */
+	mov	SGX_ENCLAVE_RUN_TSC(%rcx), %rbx
+	lea	.Lasync_exit_pointer(%rip), %rcx
+
+	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
+.Lasync_exit_pointer:
+.Lenclu_eenter_eresume:
+	enclu
+
+	/* EEXIT jumps here unless the enclave is doing something fancy. */
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
+
+	/* Set exit_reason. */
+	movl	$SGX_SYNCHRONOUS_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
+
+	/* Invoke userspace's exit handler if one was provided. */
+.Lhandle_exit:
+	cmpq	$0, SGX_ENCLAVE_RUN_USER_HANDLER(%rbx)
+	jne	.Linvoke_userspace_handler
+
+	/* Success, in the sense that ENCLU was attempted. */
+	xor	%eax, %eax
+
+.Lout:
+	pop	%rbx
+	leave
+	.cfi_def_cfa		%rsp, 8
+	ret
+
+	/* The out-of-line code runs with the pre-leave stack frame. */
+	.cfi_def_cfa		%rbp, 16
+
+.Linvalid_input:
+	mov	$(-EINVAL), %eax
+	jmp	.Lout
+
+.Lhandle_exception:
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
+
+	/* Set the exit_reason and exception info. */
+	movl	$SGX_EXCEPTION_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
+
+	mov	%eax, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_LEAF)(%rbx)
+	mov	%di,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_TRAPNR)(%rbx)
+	mov	%si,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ERROR_CODE)(%rbx)
+	mov	%rdx, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ADDRESS)(%rbx)
+	jmp	.Lhandle_exit
+
+.Linvoke_userspace_handler:
+	/* Pass the untrusted RSP (at exit) to the callback via %rcx. */
+	mov	%rsp, %rcx
+
+	/* Save @e, %rbx is about to be clobbered. */
+	mov	%rbx, %rax
+
+	/* Save the untrusted RSP offset in %rbx (non-volatile register). */
+	mov	%rsp, %rbx
+	and	$0xf, %rbx
+
+	/*
+	 * Align stack per x86_64 ABI. Note, %rsp needs to be 16-byte aligned
+	 * _after_ pushing the parameters on the stack, hence the bonus push.
+	 */
+	and	$-0x10, %rsp
+	push	%rax
+
+	/* Push @e as a param to the callback. */
+	push	%rax
+
+	/* Clear RFLAGS.DF per x86_64 ABI */
+	cld
+
+	/* Load the callback pointer to %rax and invoke it via retpoline. */
+	mov	SGX_ENCLAVE_RUN_USER_HANDLER(%rax), %rax
+	call	.Lretpoline
+
+	/* Undo the post-exit %rsp adjustment. */
+	lea	0x10(%rsp, %rbx), %rsp
+
+	/*
+	 * If the return from callback is zero or negative, return immediately,
+	 * else re-execute ENCLU with the postive return value interpreted as
+	 * the requested ENCLU leaf.
+	 */
+	cmp	$0, %eax
+	jle	.Lout
+	jmp	.Lenter_enclave
+
+.Lretpoline:
+	call	2f
+1:	pause
+	lfence
+	jmp	1b
+2:	mov	%rax, (%rsp)
+	ret
+	.cfi_endproc
+
+_ASM_VDSO_EXTABLE_HANDLE(.Lenclu_eenter_eresume, .Lhandle_exception)
+
+SYM_FUNC_END(__vdso_sgx_enter_enclave)
diff --git a/arch/x86/include/asm/enclu.h b/arch/x86/include/asm/enclu.h
new file mode 100644
index 000000000000..06157b3e9ede
--- /dev/null
+++ b/arch/x86/include/asm/enclu.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ENCLU_H
+#define _ASM_X86_ENCLU_H
+
+#define EENTER	0x02
+#define ERESUME	0x03
+
+#endif /* _ASM_X86_ENCLU_H */
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index d0916fb9629e..1564d7f88597 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -72,4 +72,132 @@ struct sgx_enclave_provision {
 	__u64 attribute_fd;
 };
 
+#define SGX_SYNCHRONOUS_EXIT	0
+#define SGX_EXCEPTION_EXIT	1
+
+struct sgx_enclave_run;
+
+/**
+ * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
+ *					__vdso_sgx_enter_enclave()
+ *
+ * @rdi:	RDI at the time of enclave exit
+ * @rsi:	RSI at the time of enclave exit
+ * @rdx:	RDX at the time of enclave exit
+ * @ursp:	RSP at the time of enclave exit (untrusted stack)
+ * @r8:		R8 at the time of enclave exit
+ * @r9:		R9 at the time of enclave exit
+ * @r:		Pointer to struct sgx_enclave_run (as provided by caller)
+ *
+ * Return:
+ *  0 or negative to exit vDSO
+ *  positive to re-enter enclave (must be EENTER or ERESUME leaf)
+ */
+typedef int (*sgx_enclave_exit_handler_t)(long rdi, long rsi, long rdx,
+					  long ursp, long r8, long r9,
+					  struct sgx_enclave_run *r);
+
+/**
+ * struct sgx_enclave_exception - structure to report exceptions encountered in
+ *				  __vdso_sgx_enter_enclave()
+ *
+ * @leaf:	ENCLU leaf from \%eax at time of exception
+ * @trapnr:	exception trap number, a.k.a. fault vector
+ * @error_code:	exception error code
+ * @address:	exception address, e.g. CR2 on a #PF
+ */
+struct sgx_enclave_exception {
+	__u32 leaf;
+	__u16 trapnr;
+	__u16 error_code;
+	__u64 address;
+};
+
+/**
+ * struct sgx_enclave_run - Control structure for __vdso_sgx_enter_enclave()
+ *
+ * @tcs:		Thread Control Structure used to enter enclave
+ * @flags:		Control flags
+ * @exit_reason:	Cause of exit from enclave, e.g. EEXIT vs. exception
+ * @user_handler:	User provided exit handler (optional)
+ * @user_data:		User provided opaque value (optional)
+ * @exception:		Valid on exit due to exception
+ */
+struct sgx_enclave_run {
+	__u64 tcs;
+	__u32 flags;
+	__u32 exit_reason;
+
+	union {
+		sgx_enclave_exit_handler_t user_handler;
+		__u64 __user_handler;
+	};
+	__u64 user_data;
+
+	union {
+		struct sgx_enclave_exception exception;
+
+		/* Pad the entire struct to 256 bytes. */
+		__u8 pad[256 - 32];
+	};
+};
+
+/**
+ * typedef vdso_sgx_enter_enclave_t - Prototype for __vdso_sgx_enter_enclave(),
+ *				      a vDSO function to enter an SGX enclave.
+ *
+ * @rdi:	Pass-through value for RDI
+ * @rsi:	Pass-through value for RSI
+ * @rdx:	Pass-through value for RDX
+ * @leaf:	ENCLU leaf, must be EENTER or ERESUME
+ * @r8:		Pass-through value for R8
+ * @r9:		Pass-through value for R9
+ * @r:		struct sgx_enclave_run, must be non-NULL
+ *
+ * NOTE: __vdso_sgx_enter_enclave() does not ensure full compliance with the
+ * x86-64 ABI, e.g. doesn't handle XSAVE state.  Except for non-volatile
+ * general purpose registers, EFLAGS.DF, and RSP alignment, preserving/setting
+ * state in accordance with the x86-64 ABI is the responsibility of the enclave
+ * and its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C
+ * code without careful consideration by both the enclave and its runtime.
+ *
+ * All general purpose registers except RAX, RBX and RCX are passed as-is to
+ * the enclave.  RAX, RBX and RCX are consumed by EENTER and ERESUME and are
+ * loaded with @leaf, asynchronous exit pointer, and @tcs respectively.
+ *
+ * RBP and the stack are used to anchor __vdso_sgx_enter_enclave() to the
+ * pre-enclave state, e.g. to retrieve @e and @handler after an enclave exit.
+ * All other registers are available for use by the enclave and its runtime,
+ * e.g. an enclave can push additional data onto the stack (and modify RSP) to
+ * pass information to the optional exit handler (see below).
+ *
+ * Most exceptions reported on ENCLU, including those that occur within the
+ * enclave, are fixed up and reported synchronously instead of being delivered
+ * via a standard signal. Debug Exceptions (#DB) and Breakpoints (#BP) are
+ * never fixed up and are always delivered via standard signals. On synchrously
+ * reported exceptions, -EFAULT is returned and details about the exception are
+ * recorded in @e, the optional sgx_enclave_exception struct.
+ *
+ * If an exit handler is provided, the handler will be invoked on synchronous
+ * exits from the enclave and for all synchronously reported exceptions. In
+ * latter case, @e is filled prior to invoking the handler.
+ *
+ * The exit handler's return value is interpreted as follows:
+ *  >0:		continue, restart __vdso_sgx_enter_enclave() with @ret as @leaf
+ *   0:		success, return @ret to the caller
+ *  <0:		error, return @ret to the caller
+ *
+ * The exit handler may transfer control, e.g. via longjmp() or C++ exception,
+ * without returning to __vdso_sgx_enter_enclave().
+ *
+ * Return:
+ *  0 on success (ENCLU reached),
+ *  -EINVAL if ENCLU leaf is not allowed,
+ *  -errno for all other negative values returned by the userspace exit handler
+ */
+typedef int (*vdso_sgx_enter_enclave_t)(unsigned long rdi, unsigned long rsi,
+					unsigned long rdx, unsigned int leaf,
+					unsigned long r8,  unsigned long r9,
+					struct sgx_enclave_run *r);
+
 #endif /* _UAPI_ASM_X86_SGX_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 22/24] selftests/x86: Add a selftest for SGX
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (20 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
  2020-09-15 11:28 ` [PATCH v38 24/24] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
  23 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, linux-kselftest, akpm,
	andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations.

Cc: linux-kselftest@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/sgx/.gitignore        |   2 +
 tools/testing/selftests/sgx/Makefile          |  53 +++
 tools/testing/selftests/sgx/call.S            |  44 ++
 tools/testing/selftests/sgx/defines.h         |  21 +
 tools/testing/selftests/sgx/load.c            | 277 ++++++++++++
 tools/testing/selftests/sgx/main.c            | 232 ++++++++++
 tools/testing/selftests/sgx/main.h            |  38 ++
 tools/testing/selftests/sgx/sigstruct.c       | 395 ++++++++++++++++++
 tools/testing/selftests/sgx/test_encl.c       |  20 +
 tools/testing/selftests/sgx/test_encl.lds     |  40 ++
 .../selftests/sgx/test_encl_bootstrap.S       |  89 ++++
 12 files changed, 1212 insertions(+)
 create mode 100644 tools/testing/selftests/sgx/.gitignore
 create mode 100644 tools/testing/selftests/sgx/Makefile
 create mode 100644 tools/testing/selftests/sgx/call.S
 create mode 100644 tools/testing/selftests/sgx/defines.h
 create mode 100644 tools/testing/selftests/sgx/load.c
 create mode 100644 tools/testing/selftests/sgx/main.c
 create mode 100644 tools/testing/selftests/sgx/main.h
 create mode 100644 tools/testing/selftests/sgx/sigstruct.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.lds
 create mode 100644 tools/testing/selftests/sgx/test_encl_bootstrap.S

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 9018f45d631d..fee80cda6304 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -68,6 +68,7 @@ TARGETS += user
 TARGETS += vm
 TARGETS += x86
 TARGETS += zram
+TARGETS += sgx
 #Please keep the TARGETS list alphabetically sorted
 # Run "make quicktest=1 run_tests" or
 # "make quicktest=1 kselftest" from top level Makefile
diff --git a/tools/testing/selftests/sgx/.gitignore b/tools/testing/selftests/sgx/.gitignore
new file mode 100644
index 000000000000..fbaf0bda9a92
--- /dev/null
+++ b/tools/testing/selftests/sgx/.gitignore
@@ -0,0 +1,2 @@
+test_sgx
+test_encl.elf
diff --git a/tools/testing/selftests/sgx/Makefile b/tools/testing/selftests/sgx/Makefile
new file mode 100644
index 000000000000..95e5c4df8014
--- /dev/null
+++ b/tools/testing/selftests/sgx/Makefile
@@ -0,0 +1,53 @@
+top_srcdir = ../../../..
+
+include ../lib.mk
+
+.PHONY: all clean
+
+CAN_BUILD_X86_64 := $(shell ../x86/check_cc.sh $(CC) \
+			    ../x86/trivial_64bit_program.c)
+
+ifndef OBJCOPY
+OBJCOPY := $(CROSS_COMPILE)objcopy
+endif
+
+INCLUDES := -I$(top_srcdir)/tools/include
+HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -z noexecstack
+ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \
+	       -fno-stack-protector -mrdrnd $(INCLUDES)
+
+TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx $(OUTPUT)/test_encl.elf
+
+ifeq ($(CAN_BUILD_X86_64), 1)
+all: $(TEST_CUSTOM_PROGS)
+endif
+
+$(OUTPUT)/test_sgx: $(OUTPUT)/main.o \
+		    $(OUTPUT)/load.o \
+		    $(OUTPUT)/sigstruct.o \
+		    $(OUTPUT)/call.o
+	$(CC) $(HOST_CFLAGS) -o $@ $^ -lcrypto
+
+$(OUTPUT)/main.o: main.c
+	$(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/load.o: load.c
+	$(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/sigstruct.o: sigstruct.c
+	$(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/call.o: call.S
+	$(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/test_encl.elf: test_encl.lds test_encl.c test_encl_bootstrap.S
+	$(CC) $(ENCL_CFLAGS) -T $^ -o $@
+
+EXTRA_CLEAN := \
+	$(OUTPUT)/test_encl.elf \
+	$(OUTPUT)/load.o \
+	$(OUTPUT)/call.o \
+	$(OUTPUT)/main.o \
+	$(OUTPUT)/sigstruct.o \
+	$(OUTPUT)/test_sgx \
+	$(OUTPUT)/test_sgx.o \
diff --git a/tools/testing/selftests/sgx/call.S b/tools/testing/selftests/sgx/call.S
new file mode 100644
index 000000000000..f640532cda93
--- /dev/null
+++ b/tools/testing/selftests/sgx/call.S
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+* Copyright(c) 2016-18 Intel Corporation.
+*/
+
+	.text
+
+	.global sgx_call_vdso
+sgx_call_vdso:
+	.cfi_startproc
+	push	%r15
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%r15, 0
+	push	%r14
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%r14, 0
+	push	%r13
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%r13, 0
+	push	%r12
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%r12, 0
+	push	%rbx
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%rbx, 0
+	push	$0
+	.cfi_adjust_cfa_offset	8
+	push	0x38(%rsp)
+	.cfi_adjust_cfa_offset	8
+	call	*eenter(%rip)
+	add	$0x10, %rsp
+	.cfi_adjust_cfa_offset	-0x10
+	pop	%rbx
+	.cfi_adjust_cfa_offset	-8
+	pop	%r12
+	.cfi_adjust_cfa_offset	-8
+	pop	%r13
+	.cfi_adjust_cfa_offset	-8
+	pop	%r14
+	.cfi_adjust_cfa_offset	-8
+	pop	%r15
+	.cfi_adjust_cfa_offset	-8
+	ret
+	.cfi_endproc
diff --git a/tools/testing/selftests/sgx/defines.h b/tools/testing/selftests/sgx/defines.h
new file mode 100644
index 000000000000..be8969922804
--- /dev/null
+++ b/tools/testing/selftests/sgx/defines.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+
+#ifndef DEFINES_H
+#define DEFINES_H
+
+#include <stdint.h>
+
+#define PAGE_SIZE 4096
+#define PAGE_MASK (~(PAGE_SIZE - 1))
+
+#define __aligned(x) __attribute__((__aligned__(x)))
+#define __packed __attribute__((packed))
+
+#include "../../../../arch/x86/kernel/cpu/sgx/arch.h"
+#include "../../../../arch/x86/include/asm/enclu.h"
+#include "../../../../arch/x86/include/uapi/asm/sgx.h"
+
+#endif /* DEFINES_H */
diff --git a/tools/testing/selftests/sgx/load.c b/tools/testing/selftests/sgx/load.c
new file mode 100644
index 000000000000..8ce0c4ac9a49
--- /dev/null
+++ b/tools/testing/selftests/sgx/load.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#include <assert.h>
+#include <elf.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include "defines.h"
+#include "main.h"
+
+void encl_delete(struct encl *encl)
+{
+	if (encl->encl_base)
+		munmap((void *)encl->encl_base, encl->encl_size);
+
+	if (encl->bin)
+		munmap(encl->bin, encl->bin_size);
+
+	if (encl->fd)
+		close(encl->fd);
+
+	if (encl->segment_tbl)
+		free(encl->segment_tbl);
+
+	memset(encl, 0, sizeof(*encl));
+}
+
+static bool encl_map_bin(const char *path, struct encl *encl)
+{
+	struct stat sb;
+	void *bin;
+	int ret;
+	int fd;
+
+	fd = open(path, O_RDONLY);
+	if (fd == -1)  {
+		perror("open()");
+		return false;
+	}
+
+	ret = stat(path, &sb);
+	if (ret) {
+		perror("stat()");
+		goto err;
+	}
+
+	bin = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+	if (bin == MAP_FAILED) {
+		perror("mmap()");
+		goto err;
+	}
+
+	encl->bin = bin;
+	encl->bin_size = sb.st_size;
+
+	close(fd);
+	return true;
+
+err:
+	close(fd);
+	return false;
+}
+
+static bool encl_ioc_create(struct encl *encl)
+{
+	struct sgx_secs *secs = &encl->secs;
+	struct sgx_enclave_create ioc;
+	int rc;
+
+	assert(encl->encl_base != 0);
+
+	memset(secs, 0, sizeof(*secs));
+	secs->ssa_frame_size = 1;
+	secs->attributes = SGX_ATTR_MODE64BIT;
+	secs->xfrm = 3;
+	secs->base = encl->encl_base;
+	secs->size = encl->encl_size;
+
+	ioc.src = (unsigned long)secs;
+	rc = ioctl(encl->fd, SGX_IOC_ENCLAVE_CREATE, &ioc);
+	if (rc) {
+		fprintf(stderr, "SGX_IOC_ENCLAVE_CREATE failed: errno=%d\n",
+			errno);
+		munmap((void *)secs->base, encl->encl_size);
+		return false;
+	}
+
+	return true;
+}
+
+static bool encl_ioc_add_pages(struct encl *encl, struct encl_segment *seg)
+{
+	struct sgx_enclave_add_pages ioc;
+	struct sgx_secinfo secinfo;
+	int rc;
+
+	memset(&secinfo, 0, sizeof(secinfo));
+	secinfo.flags = seg->flags;
+
+	ioc.src = (uint64_t)encl->src + seg->offset;
+	ioc.offset = seg->offset;
+	ioc.length = seg->size;
+	ioc.secinfo = (unsigned long)&secinfo;
+	ioc.flags = SGX_PAGE_MEASURE;
+
+	rc = ioctl(encl->fd, SGX_IOC_ENCLAVE_ADD_PAGES, &ioc);
+	if (rc < 0) {
+		fprintf(stderr, "SGX_IOC_ENCLAVE_ADD_PAGES failed: errno=%d.\n",
+			errno);
+		return false;
+	}
+
+	return true;
+}
+
+bool encl_load(const char *path, struct encl *encl)
+{
+	Elf64_Phdr *phdr_tbl;
+	off_t src_offset;
+	Elf64_Ehdr *ehdr;
+	int i, j;
+	int ret;
+
+	memset(encl, 0, sizeof(*encl));
+
+	ret = open("/dev/sgx/enclave", O_RDWR);
+	if (ret < 0) {
+		fprintf(stderr, "Unable to open /dev/sgx\n");
+		goto err;
+	}
+
+	encl->fd = ret;
+
+	if (!encl_map_bin(path, encl))
+		goto err;
+
+	ehdr = encl->bin;
+	phdr_tbl = encl->bin + ehdr->e_phoff;
+
+	for (i = 0; i < ehdr->e_phnum; i++) {
+		Elf64_Phdr *phdr = &phdr_tbl[i];
+
+		if (phdr->p_type == PT_LOAD)
+			encl->nr_segments++;
+	}
+
+	encl->segment_tbl = calloc(encl->nr_segments,
+				   sizeof(struct encl_segment));
+	if (!encl->segment_tbl)
+		goto err;
+
+	for (i = 0, j = 0; i < ehdr->e_phnum; i++) {
+		Elf64_Phdr *phdr = &phdr_tbl[i];
+		unsigned int flags = phdr->p_flags;
+		struct encl_segment *seg;
+
+		if (phdr->p_type != PT_LOAD)
+			continue;
+
+		seg = &encl->segment_tbl[j];
+
+		if (!!(flags & ~(PF_R | PF_W | PF_X))) {
+			fprintf(stderr,
+				"%d has invalid segment flags 0x%02x.\n", i,
+				phdr->p_flags);
+			goto err;
+		}
+
+		if (j == 0 && flags != (PF_R | PF_W)) {
+			fprintf(stderr,
+				"TCS has invalid segment flags 0x%02x.\n",
+				phdr->p_flags);
+			goto err;
+		}
+
+		if (j == 0) {
+			src_offset = (phdr->p_offset & PAGE_MASK) - src_offset;
+
+			seg->prot = PROT_READ | PROT_WRITE;
+			seg->flags = SGX_PAGE_TYPE_TCS << 8;
+		} else  {
+			seg->prot = (phdr->p_flags & PF_R) ? PROT_READ : 0;
+			seg->prot |= (phdr->p_flags & PF_W) ? PROT_WRITE : 0;
+			seg->prot |= (phdr->p_flags & PF_X) ? PROT_EXEC : 0;
+			seg->flags = (SGX_PAGE_TYPE_REG << 8) | seg->prot;
+		}
+
+		seg->offset = (phdr->p_offset & PAGE_MASK) - src_offset;
+		seg->size = (phdr->p_filesz + PAGE_SIZE - 1) & PAGE_MASK;
+
+		printf("0x%016lx 0x%016lx 0x%02x\n", seg->offset, seg->size,
+		       seg->prot);
+
+		j++;
+	}
+
+	assert(j == encl->nr_segments);
+
+	encl->src = encl->bin + src_offset;
+	encl->src_size = encl->segment_tbl[j - 1].offset +
+			 encl->segment_tbl[j - 1].size;
+
+	for (encl->encl_size = 4096; encl->encl_size < encl->src_size; )
+		encl->encl_size <<= 1;
+
+	return true;
+
+err:
+	encl_delete(encl);
+	return false;
+}
+
+static bool encl_map_area(struct encl *encl)
+{
+	size_t encl_size = encl->encl_size;
+	void *area;
+
+	area = mmap(NULL, encl_size * 2, PROT_NONE,
+		    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+	if (area == MAP_FAILED) {
+		perror("mmap");
+		return false;
+	}
+
+	encl->encl_base = ((uint64_t)area + encl_size - 1) & ~(encl_size - 1);
+
+	munmap(area, encl->encl_base - (uint64_t)area);
+	munmap((void *)(encl->encl_base + encl_size),
+	       (uint64_t)area + encl_size - encl->encl_base);
+
+	return true;
+}
+
+bool encl_build(struct encl *encl)
+{
+	struct sgx_enclave_init ioc;
+	int ret;
+	int i;
+
+	if (!encl_map_area(encl))
+		return false;
+
+	if (!encl_ioc_create(encl))
+		return false;
+
+	/*
+	 * Pages must be added before mapping VMAs because their permissions
+	 * cap the VMA permissions.
+	 */
+	for (i = 0; i < encl->nr_segments; i++) {
+		struct encl_segment *seg = &encl->segment_tbl[i];
+
+		if (!encl_ioc_add_pages(encl, seg))
+			return false;
+	}
+
+	ioc.sigstruct = (uint64_t)&encl->sigstruct;
+	ret = ioctl(encl->fd, SGX_IOC_ENCLAVE_INIT, &ioc);
+	if (ret) {
+		fprintf(stderr, "SGX_IOC_ENCLAVE_INIT failed: errno=%d\n",
+			errno);
+		return false;
+	}
+
+	return true;
+}
diff --git a/tools/testing/selftests/sgx/main.c b/tools/testing/selftests/sgx/main.c
new file mode 100644
index 000000000000..44acb3c72067
--- /dev/null
+++ b/tools/testing/selftests/sgx/main.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#include <elf.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include "defines.h"
+#include "main.h"
+
+static const uint64_t MAGIC = 0x1122334455667788ULL;
+vdso_sgx_enter_enclave_t eenter;
+
+struct vdso_symtab {
+	Elf64_Sym *elf_symtab;
+	const char *elf_symstrtab;
+	Elf64_Word *elf_hashtab;
+};
+
+static void *vdso_get_base_addr(char *envp[])
+{
+	Elf64_auxv_t *auxv;
+	int i;
+
+	for (i = 0; envp[i]; i++)
+		;
+
+	auxv = (Elf64_auxv_t *)&envp[i + 1];
+
+	for (i = 0; auxv[i].a_type != AT_NULL; i++) {
+		if (auxv[i].a_type == AT_SYSINFO_EHDR)
+			return (void *)auxv[i].a_un.a_val;
+	}
+
+	return NULL;
+}
+
+static Elf64_Dyn *vdso_get_dyntab(void *addr)
+{
+	Elf64_Ehdr *ehdr = addr;
+	Elf64_Phdr *phdrtab = addr + ehdr->e_phoff;
+	int i;
+
+	for (i = 0; i < ehdr->e_phnum; i++)
+		if (phdrtab[i].p_type == PT_DYNAMIC)
+			return addr + phdrtab[i].p_offset;
+
+	return NULL;
+}
+
+static void *vdso_get_dyn(void *addr, Elf64_Dyn *dyntab, Elf64_Sxword tag)
+{
+	int i;
+
+	for (i = 0; dyntab[i].d_tag != DT_NULL; i++)
+		if (dyntab[i].d_tag == tag)
+			return addr + dyntab[i].d_un.d_ptr;
+
+	return NULL;
+}
+
+static bool vdso_get_symtab(void *addr, struct vdso_symtab *symtab)
+{
+	Elf64_Dyn *dyntab = vdso_get_dyntab(addr);
+
+	symtab->elf_symtab = vdso_get_dyn(addr, dyntab, DT_SYMTAB);
+	if (!symtab->elf_symtab)
+		return false;
+
+	symtab->elf_symstrtab = vdso_get_dyn(addr, dyntab, DT_STRTAB);
+	if (!symtab->elf_symstrtab)
+		return false;
+
+	symtab->elf_hashtab = vdso_get_dyn(addr, dyntab, DT_HASH);
+	if (!symtab->elf_hashtab)
+		return false;
+
+	return true;
+}
+
+static unsigned long elf_sym_hash(const char *name)
+{
+	unsigned long h = 0, high;
+
+	while (*name) {
+		h = (h << 4) + *name++;
+		high = h & 0xf0000000;
+
+		if (high)
+			h ^= high >> 24;
+
+		h &= ~high;
+	}
+
+	return h;
+}
+
+static Elf64_Sym *vdso_symtab_get(struct vdso_symtab *symtab, const char *name)
+{
+	Elf64_Word bucketnum = symtab->elf_hashtab[0];
+	Elf64_Word *buckettab = &symtab->elf_hashtab[2];
+	Elf64_Word *chaintab = &symtab->elf_hashtab[2 + bucketnum];
+	Elf64_Sym *sym;
+	Elf64_Word i;
+
+	for (i = buckettab[elf_sym_hash(name) % bucketnum]; i != STN_UNDEF;
+	     i = chaintab[i]) {
+		sym = &symtab->elf_symtab[i];
+		if (!strcmp(name, &symtab->elf_symstrtab[sym->st_name]))
+			return sym;
+	}
+
+	return NULL;
+}
+
+int check_result(struct sgx_enclave_run *run, int ret, uint64_t result,
+		 const char *test)
+{
+	if (ret) {
+		printf("FAIL: %s() returned: %d\n", test, ret);
+		return ret;
+	} else if (run->exit_reason != SGX_SYNCHRONOUS_EXIT) {
+		printf("FAIL: %s() exit reason, expected: %u, got: %u\n",
+		       test, SGX_SYNCHRONOUS_EXIT, run->exit_reason);
+		return -EIO;
+	} else if (result != MAGIC) {
+		printf("FAIL: %s(), expected: 0x%lx, got: 0x%lx\n",
+		       test, MAGIC, result);
+		return -EIO;
+	} else if (run->user_data) {
+		printf("FAIL: %s() user data, expected: 0x0, got: 0x%llx\n",
+		       test, run->user_data);
+		return -EIO;
+	}
+	return 0;
+}
+
+static int exit_handler(long rdi, long rsi, long rdx, long ursp, long r8, long r9,
+			struct sgx_enclave_run *run)
+{
+	run->user_data = 0;
+	return 0;
+}
+
+int main(int argc, char *argv[], char *envp[])
+{
+	struct sgx_enclave_run run;
+	struct vdso_symtab symtab;
+	Elf64_Sym *eenter_sym;
+	uint64_t result = 0;
+	struct encl encl;
+	unsigned int i;
+	void *addr;
+	int ret;
+
+	if (!encl_load("test_encl.elf", &encl))
+		goto err;
+
+	if (!encl_measure(&encl))
+		goto err;
+
+	if (!encl_build(&encl))
+		goto err;
+
+	/*
+	 * An enclave consumer only must do this.
+	 */
+	for (i = 0; i < encl.nr_segments; i++) {
+		struct encl_segment *seg = &encl.segment_tbl[i];
+
+		addr = mmap((void *)encl.encl_base + seg->offset, seg->size,
+			    seg->prot, MAP_SHARED | MAP_FIXED, encl.fd, 0);
+		if (addr == MAP_FAILED) {
+			fprintf(stderr, "mmap() failed, errno=%d.\n", errno);
+			exit(1);
+		}
+	}
+
+	memset(&run, 0, sizeof(run));
+	run.tcs = encl.encl_base;
+
+	addr = vdso_get_base_addr(envp);
+	if (!addr)
+		goto err;
+
+	if (!vdso_get_symtab(addr, &symtab))
+		goto err;
+
+	eenter_sym = vdso_symtab_get(&symtab, "__vdso_sgx_enter_enclave");
+	if (!eenter_sym)
+		goto err;
+
+	eenter = addr + eenter_sym->st_value;
+
+	ret = sgx_call_vdso((void *)&MAGIC, &result, 0, EENTER, NULL, NULL, &run);
+	if (check_result(&run, ret, result, "sgx_call_vdso"))
+		goto err;
+
+
+	/* Invoke the vDSO directly. */
+	result = 0;
+	ret = eenter((unsigned long)&MAGIC, (unsigned long)&result, 0, EENTER,
+		     0, 0, &run);
+	if (check_result(&run, ret, result, "eenter"))
+		goto err;
+
+	/* And with an exit handler. */
+	run.user_handler = exit_handler;
+	run.user_data = 0xdeadbeef;
+	ret = eenter((unsigned long)&MAGIC, (unsigned long)&result, 0, EENTER,
+		     0, 0, &run);
+	if (check_result(&run, ret, result, "exit_handler"))
+		goto err;
+
+	printf("SUCCESS\n");
+	encl_delete(&encl);
+	exit(0);
+
+err:
+	encl_delete(&encl);
+	exit(1);
+}
diff --git a/tools/testing/selftests/sgx/main.h b/tools/testing/selftests/sgx/main.h
new file mode 100644
index 000000000000..2b4777942500
--- /dev/null
+++ b/tools/testing/selftests/sgx/main.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+
+#ifndef MAIN_H
+#define MAIN_H
+
+struct encl_segment {
+	off_t offset;
+	size_t size;
+	unsigned int prot;
+	unsigned int flags;
+};
+
+struct encl {
+	int fd;
+	void *bin;
+	off_t bin_size;
+	void *src;
+	size_t src_size;
+	size_t encl_size;
+	off_t encl_base;
+	unsigned int nr_segments;
+	struct encl_segment *segment_tbl;
+	struct sgx_secs secs;
+	struct sgx_sigstruct sigstruct;
+};
+
+void encl_delete(struct encl *ctx);
+bool encl_load(const char *path, struct encl *encl);
+bool encl_measure(struct encl *encl);
+bool encl_build(struct encl *encl);
+
+int sgx_call_vdso(void *rdi, void *rsi, long rdx, u32 leaf, void *r8, void *r9,
+		  struct sgx_enclave_run *run);
+
+#endif /* MAIN_H */
diff --git a/tools/testing/selftests/sgx/sigstruct.c b/tools/testing/selftests/sgx/sigstruct.c
new file mode 100644
index 000000000000..ceddad478672
--- /dev/null
+++ b/tools/testing/selftests/sgx/sigstruct.c
@@ -0,0 +1,395 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#define _GNU_SOURCE
+#include <assert.h>
+#include <getopt.h>
+#include <stdbool.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <openssl/err.h>
+#include <openssl/pem.h>
+#include "defines.h"
+#include "main.h"
+
+struct q1q2_ctx {
+	BN_CTX *bn_ctx;
+	BIGNUM *m;
+	BIGNUM *s;
+	BIGNUM *q1;
+	BIGNUM *qr;
+	BIGNUM *q2;
+};
+
+static void free_q1q2_ctx(struct q1q2_ctx *ctx)
+{
+	BN_CTX_free(ctx->bn_ctx);
+	BN_free(ctx->m);
+	BN_free(ctx->s);
+	BN_free(ctx->q1);
+	BN_free(ctx->qr);
+	BN_free(ctx->q2);
+}
+
+static bool alloc_q1q2_ctx(const uint8_t *s, const uint8_t *m,
+			   struct q1q2_ctx *ctx)
+{
+	ctx->bn_ctx = BN_CTX_new();
+	ctx->s = BN_bin2bn(s, SGX_MODULUS_SIZE, NULL);
+	ctx->m = BN_bin2bn(m, SGX_MODULUS_SIZE, NULL);
+	ctx->q1 = BN_new();
+	ctx->qr = BN_new();
+	ctx->q2 = BN_new();
+
+	if (!ctx->bn_ctx || !ctx->s || !ctx->m || !ctx->q1 || !ctx->qr ||
+	    !ctx->q2) {
+		free_q1q2_ctx(ctx);
+		return false;
+	}
+
+	return true;
+}
+
+static bool calc_q1q2(const uint8_t *s, const uint8_t *m, uint8_t *q1,
+		      uint8_t *q2)
+{
+	struct q1q2_ctx ctx;
+
+	if (!alloc_q1q2_ctx(s, m, &ctx)) {
+		fprintf(stderr, "Not enough memory for Q1Q2 calculation\n");
+		return false;
+	}
+
+	if (!BN_mul(ctx.q1, ctx.s, ctx.s, ctx.bn_ctx))
+		goto out;
+
+	if (!BN_div(ctx.q1, ctx.qr, ctx.q1, ctx.m, ctx.bn_ctx))
+		goto out;
+
+	if (BN_num_bytes(ctx.q1) > SGX_MODULUS_SIZE) {
+		fprintf(stderr, "Too large Q1 %d bytes\n",
+			BN_num_bytes(ctx.q1));
+		goto out;
+	}
+
+	if (!BN_mul(ctx.q2, ctx.s, ctx.qr, ctx.bn_ctx))
+		goto out;
+
+	if (!BN_div(ctx.q2, NULL, ctx.q2, ctx.m, ctx.bn_ctx))
+		goto out;
+
+	if (BN_num_bytes(ctx.q2) > SGX_MODULUS_SIZE) {
+		fprintf(stderr, "Too large Q2 %d bytes\n",
+			BN_num_bytes(ctx.q2));
+		goto out;
+	}
+
+	BN_bn2bin(ctx.q1, q1);
+	BN_bn2bin(ctx.q2, q2);
+
+	free_q1q2_ctx(&ctx);
+	return true;
+out:
+	free_q1q2_ctx(&ctx);
+	return false;
+}
+
+struct sgx_sigstruct_payload {
+	struct sgx_sigstruct_header header;
+	struct sgx_sigstruct_body body;
+};
+
+static bool check_crypto_errors(void)
+{
+	int err;
+	bool had_errors = false;
+	const char *filename;
+	int line;
+	char str[256];
+
+	for ( ; ; ) {
+		if (ERR_peek_error() == 0)
+			break;
+
+		had_errors = true;
+		err = ERR_get_error_line(&filename, &line);
+		ERR_error_string_n(err, str, sizeof(str));
+		fprintf(stderr, "crypto: %s: %s:%d\n", str, filename, line);
+	}
+
+	return had_errors;
+}
+
+static inline const BIGNUM *get_modulus(RSA *key)
+{
+#if OPENSSL_VERSION_NUMBER < 0x10100000L
+	return key->n;
+#else
+	const BIGNUM *n;
+
+	RSA_get0_key(key, &n, NULL, NULL);
+	return n;
+#endif
+}
+
+static RSA *gen_sign_key(void)
+{
+	BIGNUM *e;
+	RSA *key;
+	int ret;
+
+	e = BN_new();
+	key = RSA_new();
+
+	if (!e || !key)
+		goto err;
+
+	ret = BN_set_word(e, RSA_3);
+	if (ret != 1)
+		goto err;
+
+	ret = RSA_generate_key_ex(key, 3072, e, NULL);
+	if (ret != 1)
+		goto err;
+
+	BN_free(e);
+
+	return key;
+
+err:
+	RSA_free(key);
+	BN_free(e);
+
+	return NULL;
+}
+
+static void reverse_bytes(void *data, int length)
+{
+	int i = 0;
+	int j = length - 1;
+	uint8_t temp;
+	uint8_t *ptr = data;
+
+	while (i < j) {
+		temp = ptr[i];
+		ptr[i] = ptr[j];
+		ptr[j] = temp;
+		i++;
+		j--;
+	}
+}
+
+enum mrtags {
+	MRECREATE = 0x0045544145524345,
+	MREADD = 0x0000000044444145,
+	MREEXTEND = 0x00444E4554584545,
+};
+
+static bool mrenclave_update(EVP_MD_CTX *ctx, const void *data)
+{
+	if (!EVP_DigestUpdate(ctx, data, 64)) {
+		fprintf(stderr, "digest update failed\n");
+		return false;
+	}
+
+	return true;
+}
+
+static bool mrenclave_commit(EVP_MD_CTX *ctx, uint8_t *mrenclave)
+{
+	unsigned int size;
+
+	if (!EVP_DigestFinal_ex(ctx, (unsigned char *)mrenclave, &size)) {
+		fprintf(stderr, "digest commit failed\n");
+		return false;
+	}
+
+	if (size != 32) {
+		fprintf(stderr, "invalid digest size = %u\n", size);
+		return false;
+	}
+
+	return true;
+}
+
+struct mrecreate {
+	uint64_t tag;
+	uint32_t ssaframesize;
+	uint64_t size;
+	uint8_t reserved[44];
+} __attribute__((__packed__));
+
+
+static bool mrenclave_ecreate(EVP_MD_CTX *ctx, uint64_t blob_size)
+{
+	struct mrecreate mrecreate;
+	uint64_t encl_size;
+
+	for (encl_size = 0x1000; encl_size < blob_size; )
+		encl_size <<= 1;
+
+	memset(&mrecreate, 0, sizeof(mrecreate));
+	mrecreate.tag = MRECREATE;
+	mrecreate.ssaframesize = 1;
+	mrecreate.size = encl_size;
+
+	if (!EVP_DigestInit_ex(ctx, EVP_sha256(), NULL))
+		return false;
+
+	return mrenclave_update(ctx, &mrecreate);
+}
+
+struct mreadd {
+	uint64_t tag;
+	uint64_t offset;
+	uint64_t flags; /* SECINFO flags */
+	uint8_t reserved[40];
+} __attribute__((__packed__));
+
+static bool mrenclave_eadd(EVP_MD_CTX *ctx, uint64_t offset, uint64_t flags)
+{
+	struct mreadd mreadd;
+
+	memset(&mreadd, 0, sizeof(mreadd));
+	mreadd.tag = MREADD;
+	mreadd.offset = offset;
+	mreadd.flags = flags;
+
+	return mrenclave_update(ctx, &mreadd);
+}
+
+struct mreextend {
+	uint64_t tag;
+	uint64_t offset;
+	uint8_t reserved[48];
+} __attribute__((__packed__));
+
+static bool mrenclave_eextend(EVP_MD_CTX *ctx, uint64_t offset,
+			      const uint8_t *data)
+{
+	struct mreextend mreextend;
+	int i;
+
+	for (i = 0; i < 0x1000; i += 0x100) {
+		memset(&mreextend, 0, sizeof(mreextend));
+		mreextend.tag = MREEXTEND;
+		mreextend.offset = offset + i;
+
+		if (!mrenclave_update(ctx, &mreextend))
+			return false;
+
+		if (!mrenclave_update(ctx, &data[i + 0x00]))
+			return false;
+
+		if (!mrenclave_update(ctx, &data[i + 0x40]))
+			return false;
+
+		if (!mrenclave_update(ctx, &data[i + 0x80]))
+			return false;
+
+		if (!mrenclave_update(ctx, &data[i + 0xC0]))
+			return false;
+	}
+
+	return true;
+}
+
+static bool mrenclave_segment(EVP_MD_CTX *ctx, struct encl *encl,
+			      struct encl_segment *seg)
+{
+	uint64_t end = seg->offset + seg->size;
+	uint64_t offset;
+
+	for (offset = seg->offset; offset < end; offset += PAGE_SIZE) {
+		if (!mrenclave_eadd(ctx, offset, seg->flags))
+			return false;
+
+		if (!mrenclave_eextend(ctx, offset, encl->src + offset))
+			return false;
+	}
+
+	return true;
+}
+
+bool encl_measure(struct encl *encl)
+{
+	uint64_t header1[2] = {0x000000E100000006, 0x0000000000010000};
+	uint64_t header2[2] = {0x0000006000000101, 0x0000000100000060};
+	struct sgx_sigstruct *sigstruct = &encl->sigstruct;
+	struct sgx_sigstruct_payload payload;
+	uint8_t digest[SHA256_DIGEST_LENGTH];
+	unsigned int siglen;
+	RSA *key = NULL;
+	EVP_MD_CTX *ctx;
+	int i;
+
+	memset(sigstruct, 0, sizeof(*sigstruct));
+
+	sigstruct->header.header1[0] = header1[0];
+	sigstruct->header.header1[1] = header1[1];
+	sigstruct->header.header2[0] = header2[0];
+	sigstruct->header.header2[1] = header2[1];
+	sigstruct->exponent = 3;
+	sigstruct->body.attributes = SGX_ATTR_MODE64BIT;
+	sigstruct->body.xfrm = 3;
+
+	/* sanity check */
+	if (check_crypto_errors())
+		goto err;
+
+	key = gen_sign_key();
+	if (!key)
+		goto err;
+
+	BN_bn2bin(get_modulus(key), sigstruct->modulus);
+
+	ctx = EVP_MD_CTX_create();
+	if (!ctx)
+		goto err;
+
+	if (!mrenclave_ecreate(ctx, encl->src_size))
+		goto err;
+
+	for (i = 0; i < encl->nr_segments; i++) {
+		struct encl_segment *seg = &encl->segment_tbl[i];
+
+		if (!mrenclave_segment(ctx, encl, seg))
+			goto err;
+	}
+
+	if (!mrenclave_commit(ctx, sigstruct->body.mrenclave))
+		goto err;
+
+	memcpy(&payload.header, &sigstruct->header, sizeof(sigstruct->header));
+	memcpy(&payload.body, &sigstruct->body, sizeof(sigstruct->body));
+
+	SHA256((unsigned char *)&payload, sizeof(payload), digest);
+
+	if (!RSA_sign(NID_sha256, digest, SHA256_DIGEST_LENGTH,
+		      sigstruct->signature, &siglen, key))
+		goto err;
+
+	if (!calc_q1q2(sigstruct->signature, sigstruct->modulus, sigstruct->q1,
+		       sigstruct->q2))
+		goto err;
+
+	/* BE -> LE */
+	reverse_bytes(sigstruct->signature, SGX_MODULUS_SIZE);
+	reverse_bytes(sigstruct->modulus, SGX_MODULUS_SIZE);
+	reverse_bytes(sigstruct->q1, SGX_MODULUS_SIZE);
+	reverse_bytes(sigstruct->q2, SGX_MODULUS_SIZE);
+
+	EVP_MD_CTX_destroy(ctx);
+	RSA_free(key);
+	return true;
+
+err:
+	EVP_MD_CTX_destroy(ctx);
+	RSA_free(key);
+	return false;
+}
diff --git a/tools/testing/selftests/sgx/test_encl.c b/tools/testing/selftests/sgx/test_encl.c
new file mode 100644
index 000000000000..ede915399742
--- /dev/null
+++ b/tools/testing/selftests/sgx/test_encl.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-18 Intel Corporation.
+
+#include <stddef.h>
+#include "defines.h"
+
+static void *memcpy(void *dest, const void *src, size_t n)
+{
+	size_t i;
+
+	for (i = 0; i < n; i++)
+		((char *)dest)[i] = ((char *)src)[i];
+
+	return dest;
+}
+
+void encl_body(void *rdi, void *rsi)
+{
+	memcpy(rsi, rdi, 8);
+}
diff --git a/tools/testing/selftests/sgx/test_encl.lds b/tools/testing/selftests/sgx/test_encl.lds
new file mode 100644
index 000000000000..0fbbda7e665e
--- /dev/null
+++ b/tools/testing/selftests/sgx/test_encl.lds
@@ -0,0 +1,40 @@
+OUTPUT_FORMAT(elf64-x86-64)
+
+PHDRS
+{
+	tcs PT_LOAD;
+	text PT_LOAD;
+	data PT_LOAD;
+}
+
+SECTIONS
+{
+	. = 0;
+	.tcs : {
+		*(.tcs*)
+	} : tcs
+
+	. = ALIGN(4096);
+	.text : {
+		*(.text*)
+		*(.rodata*)
+	} : text
+
+	. = ALIGN(4096);
+	.data : {
+		*(.data*)
+	} : data
+
+	/DISCARD/ : {
+		*(.comment*)
+		*(.note*)
+		*(.debug*)
+		*(.eh_frame*)
+	}
+}
+
+ASSERT(!DEFINED(.altinstructions), "ALTERNATIVES are not supported in enclaves")
+ASSERT(!DEFINED(.altinstr_replacement), "ALTERNATIVES are not supported in enclaves")
+ASSERT(!DEFINED(.discard.retpoline_safe), "RETPOLINE ALTERNATIVES are not supported in enclaves")
+ASSERT(!DEFINED(.discard.nospec), "RETPOLINE ALTERNATIVES are not supported in enclaves")
+ASSERT(!DEFINED(.got.plt), "Libcalls are not supported in enclaves")
diff --git a/tools/testing/selftests/sgx/test_encl_bootstrap.S b/tools/testing/selftests/sgx/test_encl_bootstrap.S
new file mode 100644
index 000000000000..6836ea86126e
--- /dev/null
+++ b/tools/testing/selftests/sgx/test_encl_bootstrap.S
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/*
+ * Copyright(c) 2016-18 Intel Corporation.
+ */
+
+	.macro ENCLU
+	.byte 0x0f, 0x01, 0xd7
+	.endm
+
+	.section ".tcs", "aw"
+	.balign	4096
+
+	.fill	1, 8, 0			# STATE (set by CPU)
+	.fill	1, 8, 0			# FLAGS
+	.quad	encl_ssa		# OSSA
+	.fill	1, 4, 0			# CSSA (set by CPU)
+	.fill	1, 4, 1			# NSSA
+	.quad	encl_entry		# OENTRY
+	.fill	1, 8, 0			# AEP (set by EENTER and ERESUME)
+	.fill	1, 8, 0			# OFSBASE
+	.fill	1, 8, 0			# OGSBASE
+	.fill	1, 4, 0xFFFFFFFF 	# FSLIMIT
+	.fill	1, 4, 0xFFFFFFFF	# GSLIMIT
+	.fill	4024, 1, 0		# Reserved
+
+	# Identical to the previous TCS.
+	.fill	1, 8, 0			# STATE (set by CPU)
+	.fill	1, 8, 0			# FLAGS
+	.quad	encl_ssa		# OSSA
+	.fill	1, 4, 0			# CSSA (set by CPU)
+	.fill	1, 4, 1			# NSSA
+	.quad	encl_entry		# OENTRY
+	.fill	1, 8, 0			# AEP (set by EENTER and ERESUME)
+	.fill	1, 8, 0			# OFSBASE
+	.fill	1, 8, 0			# OGSBASE
+	.fill	1, 4, 0xFFFFFFFF 	# FSLIMIT
+	.fill	1, 4, 0xFFFFFFFF	# GSLIMIT
+	.fill	4024, 1, 0		# Reserved
+
+	.text
+
+encl_entry:
+	# RBX contains the base address for TCS, which is also the first address
+	# inside the enclave. By adding the value of le_stack_end to it, we get
+	# the absolute address for the stack.
+	lea	(encl_stack)(%rbx), %rax
+	xchg	%rsp, %rax
+	push	%rax
+
+	push	%rcx # push the address after EENTER
+	push	%rbx # push the enclave base address
+
+	call	encl_body
+
+	pop	%rbx # pop the enclave base address
+
+	/* Clear volatile GPRs, except RAX (EEXIT leaf). */
+	xor     %rcx, %rcx
+	xor     %rdx, %rdx
+	xor     %rdi, %rdi
+	xor     %rsi, %rsi
+	xor     %r8, %r8
+	xor     %r9, %r9
+	xor     %r10, %r10
+	xor     %r11, %r11
+
+	# Reset status flags.
+	add     %rdx, %rdx # OF = SF = AF = CF = 0; ZF = PF = 1
+
+	# Prepare EEXIT target by popping the address of the instruction after
+	# EENTER to RBX.
+	pop	%rbx
+
+	# Restore the caller stack.
+	pop	%rax
+	mov	%rax, %rsp
+
+	# EEXIT
+	mov	$4, %rax
+	enclu
+
+	.section ".data", "aw"
+
+encl_ssa:
+	.space 4096
+
+	.balign 4096
+	.space 8192
+encl_stack:
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (21 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 22/24] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-23 13:50   ` Borislav Petkov
  2020-09-15 11:28 ` [PATCH v38 24/24] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, linux-doc, Randy Dunlap,
	Sean Christopherson, akpm, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #0: Type: text/plain; charset=a, Size: 9478 bytes --]

Document the Intel SGX kernel architecture. The fine-grained micro
architecture details can be looked up from Intel SDM Volume 3D.

Cc: linux-doc@vger.kernel.org
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/x86/index.rst |   1 +
 Documentation/x86/sgx.rst   | 200 ++++++++++++++++++++++++++++++++++++
 2 files changed, 201 insertions(+)
 create mode 100644 Documentation/x86/sgx.rst

diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 265d9e9a093b..807290bf357c 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -30,3 +30,4 @@ x86-specific Documentation
    usb-legacy-support
    i386/index
    x86_64/index
+   sgx
diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
new file mode 100644
index 000000000000..706a846ae353
--- /dev/null
+++ b/Documentation/x86/sgx.rst
@@ -0,0 +1,200 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+Architecture
+============
+
+*Software Guard eXtensions (SGX)* is a set of instructions that enable ring-3
+applications to set aside private regions of code and data. These regions are
+called enclaves. An enclave can be entered to a fixed set of entry points. Only
+a CPU running inside the enclave can access its code and data.
+
+The support can be determined by
+
+	``grep sgx /proc/cpuinfo``
+
+Enclave Page Cache
+==================
+
+SGX utilizes an *Enclave Page Cache (EPC)* to store pages that are associated
+with an enclave. It is contained in a BIOS reserved region of physical memory.
+Unlike pages used for regular memory, pages can only be accessed outside the
+enclave for different purposes with the instructions **ENCLS**, **ENCLV** and
+**ENCLU**.
+
+Direct memory accesses to an enclave can be only done by a CPU executing inside
+the enclave. An enclave can be entered with **ENCLU[EENTER]** to a fixed set of
+entry points. However, a CPU executing inside the enclave can do outside memory
+accesses.
+
+Page Types
+----------
+
+**SGX Enclave Control Structure (SECS)**
+   Enclave's address range, attributes and other global data are defined
+   by this structure.
+
+**Regular (REG)**
+   Regular EPC pages contain the code and data of an enclave.
+
+**Thread Control Structure (TCS)**
+   Thread Control Structure pages define the entry points to an enclave and
+   track the execution state of an enclave thread.
+
+**Version Array (VA)**
+   Version Array pages contain 512 slots, each of which can contain a version
+   number for a page evicted from the EPC.
+
+Enclave Page Cache Map
+----------------------
+
+The processor tracks EPC pages via the *Enclave Page Cache Map (EPCM)*.  EPCM
+contains an entry for each EPC page, which describes the owning enclave, access
+rights and page type among the other things.
+
+The permissions from EPCM is consulted if and only if walking the kernel page
+tables succeeds. The total permissions are thus a conjunction between page table
+and EPCM permissions.
+
+For all intents and purposes the SGX architecture allows the processor to
+invalidate all EPCM entries at will, i.e. requires that software be prepared to
+handle an EPCM fault at any time. The contents of EPC are encrypted with an
+ephemeral key, which is lost on power transitions.
+
+EPC management
+==============
+
+EPC pages do not have ``struct page`` instances. They are IO memory from kernel
+perspective. The consequence is that they are always mapped as shared memory.
+Kernel defines ``/dev/sgx/enclave`` that can be mapped as ``MAP_SHARED`` to
+define the address range for an enclave.
+
+EPC Over-subscription
+=====================
+
+When the amount of free EPC pages goes below a low watermark the swapping thread
+starts reclaiming pages. The pages that do not have the **A** bit set are
+selected as victim pages.
+
+Launch Control
+==============
+
+SGX provides a launch control mechanism. After all enclave pages have been
+copied, kernel executes **ENCLS[EINIT]**, which initializes the enclave. Only
+after this the CPU can execute inside the enclave.
+
+This leaf function takes an RSA-3072 signature of the enclave measurement and an
+optional cryptographic token. Linux does not take advantage of launch tokens.
+The instruction checks that the signature is signed with the key defined in
+**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the
+enclave is allowed to be executed.
+
+MSRs can be configured by the BIOS to be either readable or writable. Linux
+supports only writable configuration in order to give full control to the kernel
+on launch control policy. Readable configuration requires the use of previously
+mentioned launch tokens.
+
+The current kernel implementation supports only writable MSRs. The launch is
+performed by setting the MSRs to the hash of the enclave signer's public key.
+The alternative would be to have *a launch enclave* that would be signed with
+the key set into MSRs, which would then generate launch tokens for other
+enclaves. This would only make sense with read-only MSRs, and thus the option
+has been discarded.
+
+Attestation
+===========
+
+Local Attestation
+-----------------
+
+In local attestation an enclave creates a **REPORT** data structure with
+**ENCLS[EREPORT]**, which describes the origin of an enclave. In particular, it
+contains a AES-CMAC of the enclave contents signed with a report key unique to
+each processor. All enclaves have access to this key.
+
+This mechanism can also be used in addition as a communication channel as the
+**REPORT** data structure includes a 64-byte field for variable information.
+
+Remote Attestation
+------------------
+
+Provisioning Certification Enclave (PCE), the root of trust for other enclaves,
+generates a signing key from a fused key called Provisioning Certification Key.
+PCE can then use this key to certify an attestation key of a Quoting Enclave
+(QE), e.g. we get the chain of trust down to the hardware if the Intel signed
+PCE is used.
+
+To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be only
+allowed for those who actually need it so that only the trusted parties can
+certify QE's.
+
+A device file called /dev/sgx/provision exists to provide file descriptors that
+act as privilege tokens for building provisioning enclaves. These can be
+associated with enclaves with the ioctl SGX_IOC_ENCLAVE_SET_ATTRIBUTE.
+
+Encryption engines
+==================
+
+In order to conceal the enclave data while it is out of the CPU package,
+memory controller has to be extended with an encryption engine. MC can then
+route incoming requests coming from CPU cores running in enclave mode to the
+encryption engine.
+
+In CPUs prior to Icelake, Memory Encryption Engine (MEE) is used to
+encrypt pages leaving the CPU caches. MEE uses a n-ary Merkle tree with root in
+SRAM to maintain integrity of the encrypted data. This provides integrity and
+anti-replay protection but does not scale to large memory sizes because the time
+required to update the Merkle tree grows logarithmically in relation to the
+memory size.
+
+CPUs starting from Icelake use Total Memory Encryption (TME) in the place of
+MEE. SGX using TME does not have an integrity Merkle tree, which means losing HW
+protections from integrity and replay-attacks, but includes additional changes
+to prevent cipher text from being return and SW memory aliases from being
+created. DMA remains blocked by the PRMRR to the EPC memory even systems that
+use TME (SDM section 41.10).
+
+Backing storage
+===============
+
+Backing storage is shared and not accounted. It is implemented as a private
+shmem file. Providing a backing storage in some form from user space is not
+possible - accounting would go to invalid state as reclaimed pages would get
+accounted to the processes of which behalf the kernel happened to be acting on.
+
+Access control
+==============
+
+`mmap()` permissions are capped by the enclave permissions. A direct
+consequence of this is that all the pages for an address range must be added
+before `mmap()` can be applied. Effectively an enclave page with minimum
+permissions in the address range sets the permission cap for the mapping
+operation.
+
+Usage Models
+============
+
+Shared Library
+--------------
+
+Sensitive data and the code that acts on it is partitioned from the application
+into a separate library. The library is then linked as a DSO which can be loaded
+into an enclave. The application can then make individual function calls into
+the enclave through special SGX instructions. A run-time within the enclave is
+configured to marshal function parameters into and out of the enclave and to
+call the correct library function.
+
+Application Container
+---------------------
+
+An application may be loaded into a container enclave which is specially
+configured with a library OS and run-time which permits the application to run.
+The enclave run-time and library OS work together to execute the application
+when a thread enters the enclave.
+
+References
+==========
+
+"Supporting Third Party Attestation for Intel® SGX with Intel® Data Center
+Attestation Primitives"
+   https://software.intel.com/sites/default/files/managed/f1/b8/intel-sgx-support-for-third-party-attestation.pdf
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 24/24] x86/sgx: Update MAINTAINERS
  2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
                   ` (22 preceding siblings ...)
  2020-09-15 11:28 ` [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
@ 2020-09-15 11:28 ` Jarkko Sakkinen
  2020-09-25 22:37   ` Sean Christopherson
  23 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:28 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Jarkko Sakkinen, Thomas Gleixner, Borislav Petkov,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, yaozhangx

Add the maintainer information for the SGX subsystem.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 MAINTAINERS | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3b186ade3597..1d4daeb12d0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9051,6 +9051,17 @@ F:	Documentation/x86/intel_txt.rst
 F:	arch/x86/kernel/tboot.c
 F:	include/linux/tboot.h
 
+INTEL SGX
+M:	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+M:	Sean Christopherson <sean.j.christopherson@intel.com>
+L:	linux-sgx@vger.kernel.org
+S:	Maintained
+Q:	https://patchwork.kernel.org/project/intel-sgx/list/
+T:	git https://github.com/jsakkine-intel/linux-sgx.git
+F:	arch/x86/include/uapi/asm/sgx.h
+F:	arch/x86/kernel/cpu/sgx/*
+K:	\bSGX_
+
 INTERCONNECT API
 M:	Georgi Djakov <georgi.djakov@linaro.org>
 L:	linux-pm@vger.kernel.org
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
  2020-09-15 11:28 ` [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
@ 2020-09-16 11:44   ` Borislav Petkov
  2020-09-16 20:30     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-16 11:44 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Jethro Beekman, Darren Kenny, Borislav Petkov, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:21PM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> Include SGX bit to the PF error codes and throw SIGSEGV with PF_SGX when
> a #PF with SGX set happens.
> 
> CPU throws a #PF with the SGX set in the event of Enclave Page Cache Map
> (EPCM) conflict. The EPCM is a CPU-internal table, which describes the
> properties for a enclave page. Enclaves are measured and signed software
> entities, which SGX hosts. [1]
> 
> Although the primary purpose of the EPCM conflict checks  is to prevent
> malicious accesses to an enclave, an illegit access can happen also for
> legit reasons.
> 
> All SGX reserved memory, including EPCM is encrypted with a transient key
> that does not survive from the power transition. Throwing a SIGSEGV allows
> user space software to react when this happens (e.g. recreate the enclave,
> which was invalidated).
> 
> [1] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM)
> 
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Reviewed-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  arch/x86/include/asm/traps.h | 14 ++++++++------

The SEV-ES patchset moved that to arch/x86/include/asm/trap_pf.h but
fixing that up is real easy. Simply do this search-replace

s!arch/x86/include/asm/traps.h!arch/x86/include/asm/trap_pf.h!

on this patch.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
  2020-09-16 11:44   ` Borislav Petkov
@ 2020-09-16 20:30     ` Jarkko Sakkinen
  2020-09-16 20:32       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-16 20:30 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Jethro Beekman, Darren Kenny, Borislav Petkov, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

On Wed, Sep 16, 2020 at 01:44:48PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:21PM +0300, Jarkko Sakkinen wrote:
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> > 
> > Include SGX bit to the PF error codes and throw SIGSEGV with PF_SGX when
> > a #PF with SGX set happens.
> > 
> > CPU throws a #PF with the SGX set in the event of Enclave Page Cache Map
> > (EPCM) conflict. The EPCM is a CPU-internal table, which describes the
> > properties for a enclave page. Enclaves are measured and signed software
> > entities, which SGX hosts. [1]
> > 
> > Although the primary purpose of the EPCM conflict checks  is to prevent
> > malicious accesses to an enclave, an illegit access can happen also for
> > legit reasons.
> > 
> > All SGX reserved memory, including EPCM is encrypted with a transient key
> > that does not survive from the power transition. Throwing a SIGSEGV allows
> > user space software to react when this happens (e.g. recreate the enclave,
> > which was invalidated).
> > 
> > [1] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM)
> > 
> > Acked-by: Jethro Beekman <jethro@fortanix.com>
> > Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> > Reviewed-by: Borislav Petkov <bp@suse.de>
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> >  arch/x86/include/asm/traps.h | 14 ++++++++------
> 
> The SEV-ES patchset moved that to arch/x86/include/asm/trap_pf.h but
> fixing that up is real easy. Simply do this search-replace
> 
> s!arch/x86/include/asm/traps.h!arch/x86/include/asm/trap_pf.h!
> 
> on this patch.

Hey, I just did

git fetch mainline && git rebase mainline/master

Zero conflicts and there is no trap_pf.h yet. So this is not yet in
Linus' tree?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
  2020-09-16 20:30     ` Jarkko Sakkinen
@ 2020-09-16 20:32       ` Borislav Petkov
  0 siblings, 0 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-16 20:32 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Jethro Beekman, Darren Kenny, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Wed, Sep 16, 2020 at 11:30:08PM +0300, Jarkko Sakkinen wrote:
> Zero conflicts and there is no trap_pf.h yet. So this is not yet in
> Linus' tree?

tip tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/seves

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
@ 2020-09-18 12:44   ` Borislav Petkov
  2020-09-18 15:09   ` Andy Lutomirski
  1 sibling, 0 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-18 12:44 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:28PM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> Add vm_ops()->mprotect() for additional constraints for a VMA.
> 
> Intel Software Guard eXtensions (SGX) will use this callback to add two
> constraints:
> 
> 1. Verify that the address range does not have holes: each page address
>    must be filled with an enclave page.
> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>    page within the address range. Enclave cryptographically sealed
>    permissions for each page address that set the upper limit for possible
>    VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> Cc: linux-mm@kvack.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  include/linux/mm.h | 3 +++
>  mm/mprotect.c      | 5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)

Needs an ACK from an mm person.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
  2020-09-18 12:44   ` Borislav Petkov
@ 2020-09-18 15:09   ` Andy Lutomirski
  2020-09-18 23:24     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect()' Jarkko Sakkinen
  2020-09-18 23:53     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Sean Christopherson
  1 sibling, 2 replies; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-18 15:09 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: X86 ML, linux-sgx, LKML, Sean Christopherson, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Andrew Lutomirski, Neil Horman,
	Nathaniel McCallum, Patrick Uiterwijk, David Rientjes,
	Thomas Gleixner, yaozhangx

On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> From: Sean Christopherson <sean.j.christopherson@intel.com>
>
> Add vm_ops()->mprotect() for additional constraints for a VMA.
>
> Intel Software Guard eXtensions (SGX) will use this callback to add two
> constraints:
>
> 1. Verify that the address range does not have holes: each page address
>    must be filled with an enclave page.
> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>    page within the address range. Enclave cryptographically sealed
>    permissions for each page address that set the upper limit for possible
>    VMA permissions. Not respecting this can cause #GP's to be emitted.

It's been awhile since I looked at this.  Can you remind us: is this
just preventing userspace from shooting itself in the foot or is this
something more important?

--Andy

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()'
  2020-09-18 15:09   ` Andy Lutomirski
@ 2020-09-18 23:24     ` Jarkko Sakkinen
  2020-09-18 23:53     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Sean Christopherson
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-18 23:24 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: X86 ML, linux-sgx, LKML, Sean Christopherson, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > Add vm_ops()->mprotect() for additional constraints for a VMA.
> >
> > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > constraints:
> >
> > 1. Verify that the address range does not have holes: each page address
> >    must be filled with an enclave page.
> > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> >    page within the address range. Enclave cryptographically sealed
> >    permissions for each page address that set the upper limit for possible
> >    VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> It's been awhile since I looked at this.  Can you remind us: is this
> just preventing userspace from shooting itself in the foot or is this
> something more important?
> 
> --Andy

Haitao found this:

https://patchwork.kernel.org/patch/10978327/

The way I understand it, for an LSM hook it makes sense that the
mprotect() can deduce a single permission for an enclave address range.
With those constraints it is possible.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-18 15:09   ` Andy Lutomirski
  2020-09-18 23:24     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect()' Jarkko Sakkinen
@ 2020-09-18 23:53     ` Sean Christopherson
  2020-09-19  0:15       ` Andy Lutomirski
       [not found]       ` <20200921124946.GF6038@linux.intel.com>
  1 sibling, 2 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-18 23:53 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Jarkko Sakkinen, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > Add vm_ops()->mprotect() for additional constraints for a VMA.
> >
> > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > constraints:
> >
> > 1. Verify that the address range does not have holes: each page address
> >    must be filled with an enclave page.
> > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> >    page within the address range. Enclave cryptographically sealed
> >    permissions for each page address that set the upper limit for possible
> >    VMA permissions. Not respecting this can cause #GP's to be emitted.

Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
that's technically an errata.  But this isn't the real motivation, e.g.
userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
simply adds another flavor.

> It's been awhile since I looked at this.  Can you remind us: is this
> just preventing userspace from shooting itself in the foot or is this
> something more important?

Something more important, it's used to prevent userspace from circumventing
a noexec filesystem by loading code into an enclave, and to give the kernel the
option of adding enclave specific LSM policies in the future.

The source file (if one exists) for the enclave is long gone when the enclave
is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
permissions for a given page are snapshotted when the page is added to the
enclave, i.e. when the enclave is built.  Enclave pages that will be executable
must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
noexec file system.

The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
permissions beyond what are allowed, e.g. trying to map an enclave page with
EXEC permissions when the page was added to the enclave without EXEC.

Future LSM policies have a similar need due to vm_file always pointing at
/dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave.
->mprotect() again allows enforcing permissions at map time that were checked
at enclave build time, e.g. via an LSM hook.

Deferring ->mprotect() until LSM support is added (if it ever is) would be
problematic due to SGX2.  With SGX2, userspace can extend permissions of an
enclave page (for the CPU's EPC Map entry, not the kernel's page tables)
without bouncing through the kernel.  Without ->mprotect () enforcement.
userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X.  We
want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so
that the hypothetical LSM hook would have all information at EADD(), i.e.
would be aware of the EXEC permission, without creating divergent behavior
based on whether or not an LSM is active.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-18 23:53     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Sean Christopherson
@ 2020-09-19  0:15       ` Andy Lutomirski
       [not found]         ` <20200922125801.GA133710@linux.intel.com>
       [not found]       ` <20200921124946.GF6038@linux.intel.com>
  1 sibling, 1 reply; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-19  0:15 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, Jarkko Sakkinen, X86 ML, linux-sgx, LKML,
	Linux-MM, Andrew Morton, Matthew Wilcox, Jethro Beekman,
	Darren Kenny, Andy Shevchenko, asapek, Borislav Petkov, Xing,
	Cedric, chenalexchen, Conrad Parker, cyhanish, Dave Hansen,
	Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx


> On Sep 18, 2020, at 4:53 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> 
> On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
>>> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
>>> <jarkko.sakkinen@linux.intel.com> wrote:
>>> 
>>> From: Sean Christopherson <sean.j.christopherson@intel.com>
>>> 
>>> Add vm_ops()->mprotect() for additional constraints for a VMA.
>>> 
>>> Intel Software Guard eXtensions (SGX) will use this callback to add two
>>> constraints:
>>> 
>>> 1. Verify that the address range does not have holes: each page address
>>>   must be filled with an enclave page.
>>> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>>>   page within the address range. Enclave cryptographically sealed
>>>   permissions for each page address that set the upper limit for possible
>>>   VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
> that's technically an errata.  But this isn't the real motivation, e.g.
> userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
> simply adds another flavor.
> 
>> It's been awhile since I looked at this.  Can you remind us: is this
>> just preventing userspace from shooting itself in the foot or is this
>> something more important?
> 
> Something more important, it's used to prevent userspace from circumventing
> a noexec filesystem by loading code into an enclave, and to give the kernel the
> option of adding enclave specific LSM policies in the future.
> 
> The source file (if one exists) for the enclave is long gone when the enclave
> is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> permissions for a given page are snapshotted when the page is added to the
> enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> noexec file system.
> 
> The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
> permissions beyond what are allowed, e.g. trying to map an enclave page with
> EXEC permissions when the page was added to the enclave without EXEC.
> 
> Future LSM policies have a similar need due to vm_file always pointing at
> /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave.
> ->mprotect() again allows enforcing permissions at map time that were checked
> at enclave build time, e.g. via an LSM hook.
> 
> Deferring ->mprotect() until LSM support is added (if it ever is) would be
> problematic due to SGX2.  With SGX2, userspace can extend permissions of an
> enclave page (for the CPU's EPC Map entry, not the kernel's page tables)
> without bouncing through the kernel.  Without ->mprotect () enforcement.
> userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X.  We
> want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so
> that the hypothetical LSM hook would have all information at EADD(), i.e.
> would be aware of the EXEC permission, without creating divergent behavior
> based on whether or not an LSM is active.

That’s what I thought. Can we get this in the changelog?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 11/24] x86/sgx: Add SGX enclave driver
  2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
@ 2020-09-21  9:30   ` Borislav Petkov
  2020-09-21 12:09     ` Jarkko Sakkinen
  2020-10-01 17:36   ` Sean Christopherson
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21  9:30 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-security-module, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> Intel Software Guard eXtensions (SGX) is a set of CPU instructions that can
> be used by applications to set aside private regions of code and data. The
> code outside the SGX hosted software entity is prevented from accessing the
> memory inside the enclave by the CPU. We call these entities as enclaves.

It was correct before:

-memory inside the enclave by the CPU. We call these entities enclaves.
+memory inside the enclave by the CPU. We call these entities as enclaves.

"as " is not needed.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-15 11:28 ` [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
@ 2020-09-21 10:03   ` Borislav Petkov
  2020-09-21 12:28     ` Jarkko Sakkinen
  2020-10-03  0:23   ` Haitao Huang
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 10:03 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:30PM +0300, Jarkko Sakkinen wrote:
> +static int sgx_validate_secs(const struct sgx_secs *secs)
> +{
> +	u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
> +		       sgx_encl_size_max_64 : sgx_encl_size_max_32;
> +
> +	if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> +		return -EINVAL;
> +
> +	if (secs->base & (secs->size - 1))
> +		return -EINVAL;
> +
> +	if (secs->miscselect & sgx_misc_reserved_mask ||
> +	    secs->attributes & sgx_attributes_reserved_mask ||
> +	    secs->xfrm & sgx_xfrm_reserved_mask)
> +		return -EINVAL;
> +
> +	if (secs->size > max_size)
> +		return -EINVAL;
> +
> +	if (!(secs->xfrm & XFEATURE_MASK_FP) ||
> +	    !(secs->xfrm & XFEATURE_MASK_SSE) ||
> +	    (((secs->xfrm >> XFEATURE_BNDREGS) & 1) !=
> +	     ((secs->xfrm >> XFEATURE_BNDCSR) & 1)))

Let that last line stick out so that you have each statement on a single line.

> +		return -EINVAL;
> +
> +	if (!secs->ssa_frame_size)
> +		return -EINVAL;
> +
> +	if (sgx_calc_ssa_frame_size(secs->miscselect, secs->xfrm) >
> +	    secs->ssa_frame_size)

Let that stick out.

> +		return -EINVAL;
> +
> +	if (memchr_inv(secs->reserved1, 0, sizeof(secs->reserved1)) ||
> +	    memchr_inv(secs->reserved2, 0, sizeof(secs->reserved2)) ||
> +	    memchr_inv(secs->reserved3, 0, sizeof(secs->reserved3)) ||
> +	    memchr_inv(secs->reserved4, 0, sizeof(secs->reserved4)))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
> +{
> +	unsigned long encl_size = secs->size + PAGE_SIZE;

You're still using secs->size before validation. I know, we will return
early if sgx_validate_secs() fails but pls move that addition after the
validation call.

...

> +/**
> + * sgx_ioc_enclave_create - handler for %SGX_IOC_ENCLAVE_CREATE
> + * @filep:	open file to /dev/sgx

Dammit, how many times do I have to type this comment here?!

"That's

@encl: enclave pointer

or so."

There's no filep - there is an encl!


> + * @arg:	userspace pointer to a struct sgx_enclave_create instance
> + *
> + * Allocate kernel data structures for a new enclave and execute ECREATE after
> + * verifying the correctness of the provided SECS.

... which is done in sgx_validate_secs()."

Yes, spell it out, otherwise one has to wonder where that validation is
happening in the function *below* because the comment is over it - not
over sgx_validate_secs().

And yes, you need to spell stuff like that out because this SGX crap is
complex and it better be properly documented!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 11/24] x86/sgx: Add SGX enclave driver
  2020-09-21  9:30   ` Borislav Petkov
@ 2020-09-21 12:09     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 12:09 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-security-module, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 11:30:06AM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that can
> > be used by applications to set aside private regions of code and data. The
> > code outside the SGX hosted software entity is prevented from accessing the
> > memory inside the enclave by the CPU. We call these entities as enclaves.
> 
> It was correct before:
> 
> -memory inside the enclave by the CPU. We call these entities enclaves.
> +memory inside the enclave by the CPU. We call these entities as enclaves.
> 
> "as " is not needed.

I reworded it. Thank you.

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-21 10:03   ` Borislav Petkov
@ 2020-09-21 12:28     ` Jarkko Sakkinen
  2020-09-21 13:51       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 12:28 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 12:03:56PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:30PM +0300, Jarkko Sakkinen wrote:
> > +static int sgx_validate_secs(const struct sgx_secs *secs)
> > +{
> > +	u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
> > +		       sgx_encl_size_max_64 : sgx_encl_size_max_32;
> > +
> > +	if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> > +		return -EINVAL;
> > +
> > +	if (secs->base & (secs->size - 1))
> > +		return -EINVAL;
> > +
> > +	if (secs->miscselect & sgx_misc_reserved_mask ||
> > +	    secs->attributes & sgx_attributes_reserved_mask ||
> > +	    secs->xfrm & sgx_xfrm_reserved_mask)
> > +		return -EINVAL;
> > +
> > +	if (secs->size > max_size)
> > +		return -EINVAL;
> > +
> > +	if (!(secs->xfrm & XFEATURE_MASK_FP) ||
> > +	    !(secs->xfrm & XFEATURE_MASK_SSE) ||
> > +	    (((secs->xfrm >> XFEATURE_BNDREGS) & 1) !=
> > +	     ((secs->xfrm >> XFEATURE_BNDCSR) & 1)))
> 
> Let that last line stick out so that you have each statement on a single line.
> 
> > +		return -EINVAL;
> > +
> > +	if (!secs->ssa_frame_size)
> > +		return -EINVAL;
> > +
> > +	if (sgx_calc_ssa_frame_size(secs->miscselect, secs->xfrm) >
> > +	    secs->ssa_frame_size)
> 
> Let that stick out.
> 
> > +		return -EINVAL;
> > +
> > +	if (memchr_inv(secs->reserved1, 0, sizeof(secs->reserved1)) ||
> > +	    memchr_inv(secs->reserved2, 0, sizeof(secs->reserved2)) ||
> > +	    memchr_inv(secs->reserved3, 0, sizeof(secs->reserved3)) ||
> > +	    memchr_inv(secs->reserved4, 0, sizeof(secs->reserved4)))
> > +		return -EINVAL;
> > +
> > +	return 0;
> > +}
> > +
> > +static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
> > +{
> > +	unsigned long encl_size = secs->size + PAGE_SIZE;
> 
> You're still using secs->size before validation. I know, we will return
> early if sgx_validate_secs() fails but pls move that addition after the
> validation call.

Is this appropriate:

	/* The extra page in swap space goes to SECS. */
	encl_size = secs->size + PAGE_SIZE;

	backing = shmem_file_setup("SGX backing", encl_size + (encl_size >> 5),
				   VM_NORESERVE);
	if (IS_ERR(backing)) {
		ret = PTR_ERR(backing);
		goto err_out_shrink;
	}

> ...
> 
> > +/**
> > + * sgx_ioc_enclave_create - handler for %SGX_IOC_ENCLAVE_CREATE
> > + * @filep:	open file to /dev/sgx
> 
> Dammit, how many times do I have to type this comment here?!
> 
> "That's
> 
> @encl: enclave pointer
> 
> or so."
> 
> There's no filep - there is an encl!

I'm not actually sure what has happened. As you can easily grep, the
rename is done in five other sites. I also see a similar problem in
EINIT, which I will fix.

git grep "enclave pointer" arch/x86/kernel/cpu/sgx/ | wc -l
5

> > + * @arg:	userspace pointer to a struct sgx_enclave_create instance
> > + *
> > + * Allocate kernel data structures for a new enclave and execute ECREATE after
> > + * verifying the correctness of the provided SECS.
> 
> ... which is done in sgx_validate_secs()."
> 
> Yes, spell it out, otherwise one has to wonder where that validation is
> happening in the function *below* because the comment is over it - not
> over sgx_validate_secs().
> 
> And yes, you need to spell stuff like that out because this SGX crap is
> complex and it better be properly documented!

I agree with this but I also think it would make sense to rephrase
"verifying the correctness of the provided SECS" with something more
informative.

I would rephrase as:

"... after checking that the provided data for SECS meets the expectations
of ENCLS[ECREATE] for an unitialized enclave and size of the address
space does not surpass the platform expectations. This validation is
executed by sgx_validate_secs()."

Is this sufficient for you, or do you have further suggestions?

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
       [not found]       ` <20200921124946.GF6038@linux.intel.com>
@ 2020-09-21 12:51         ` Jarkko Sakkinen
  2020-09-21 13:14         ` Jarkko Sakkinen
       [not found]         ` <20200921165758.GA24156@linux.intel.com>
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 12:51 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote:
> What really should be documented is to answer why we consider an enclave
                                      ~~
				      the (editing mistake)

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
       [not found]       ` <20200921124946.GF6038@linux.intel.com>
  2020-09-21 12:51         ` Jarkko Sakkinen
@ 2020-09-21 13:14         ` Jarkko Sakkinen
       [not found]         ` <20200921165758.GA24156@linux.intel.com>
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 13:14 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote:
> The 2nd part of the answer is the answer to the question: why we want to
> feed LSM hooks enclaves exactly in this state.

The question can be further refined as why: why this is the best
possible set of substates to filter in?

"no holes" part is obvious as the consequence of not surpassing
permissions of any of the pages in range, as you could otherwise
break the state with ioctl(SGX_ENCLAVE_ADD_PAGES) with permssions
that are below the mmap permissions.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-21 12:28     ` Jarkko Sakkinen
@ 2020-09-21 13:51       ` Borislav Petkov
  2020-09-21 19:29         ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 13:51 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 03:28:23PM +0300, Jarkko Sakkinen wrote:
> Is this appropriate:
> 
> 	/* The extra page in swap space goes to SECS. */
> 	encl_size = secs->size + PAGE_SIZE;
> 
> 	backing = shmem_file_setup("SGX backing", encl_size + (encl_size >> 5),
> 				   VM_NORESERVE);
> 	if (IS_ERR(backing)) {
> 		ret = PTR_ERR(backing);
> 		goto err_out_shrink;
> 	}
>

Yap, thanks.

> I agree with this but I also think it would make sense to rephrase
> "verifying the correctness of the provided SECS" with something more
> informative.
> 
> I would rephrase as:
> 
> "... after checking that the provided data for SECS meets the expectations
> of ENCLS[ECREATE] for an unitialized enclave and size of the address
> space does not surpass the platform expectations. This validation is
> executed by sgx_validate_secs()."

s/executed/done/

> Is this sufficient for you, or do you have further suggestions?

Yes, no further suggestions.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-15 11:28 ` [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT Jarkko Sakkinen
@ 2020-09-21 17:35   ` Borislav Petkov
  2020-09-21 18:10     ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 17:35 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:32PM +0300, Jarkko Sakkinen wrote:
> +static int sgx_einit(struct sgx_sigstruct *sigstruct, void *token,
> +		     struct sgx_epc_page *secs, u64 *lepubkeyhash)
> +{
> +	int ret;
> +
> +	preempt_disable();
> +	sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);

So this will update the cached copies *and* the MSRs itself if what's
cached is stale...

> +	ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
> +	if (ret == SGX_INVALID_EINITTOKEN) {

... so why would it return this error here?

Definition of this error says:

 * %SGX_INVALID_EINITTOKEN:     EINITTOKEN is invalid and enclave signer's
 *                              public key does not match IA32_SGXLEPUBKEYHASH.

when you just updated them?!

> +		sgx_update_lepubkeyhash_msrs(lepubkeyhash, true);

So why force a second time?

> +		ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
> +	}
> +	preempt_enable();
> +	return ret;
> +}
> +
> +static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct *sigstruct,
> +			 void *token)
> +{
> +	u64 mrsigner[4];
> +	int ret;
> +	int i;
> +	int j;
> +
> +	/* Deny initializing enclaves with attributes (namely provisioning)
> +	 * that have not been explicitly allowed.
> +	 */

Comments style is with the first line empty:

	/*
	 * A sentence ending with a full-stop.
	 * Another sentence. ...
	 * More sentences. ...
	 */

> +	if (encl->attributes & ~encl->attributes_mask)
> +		return -EACCES;
> +
> +	ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);
> +	if (ret)
> +		return ret;
> +
> +	mutex_lock(&encl->lock);
> +
> +	/*
> +	 * ENCLS[EINIT] is interruptible because it has such a high latency,
> +	 * e.g. 50k+ cycles on success. If an IRQ/NMI/SMI becomes pending,
> +	 * EINIT may fail with SGX_UNMASKED_EVENT so that the event can be
> +	 * serviced.
> +	 */
> +	for (i = 0; i < SGX_EINIT_SLEEP_COUNT; i++) {
> +		for (j = 0; j < SGX_EINIT_SPIN_COUNT; j++) {
> +			ret = sgx_einit(sigstruct, token, encl->secs.epc_page,
> +					mrsigner);
> +			if (ret == SGX_UNMASKED_EVENT)
> +				continue;
> +			else
> +				break;
> +		}
> +
> +		if (ret != SGX_UNMASKED_EVENT)
> +			break;
> +
> +		msleep_interruptible(SGX_EINIT_SLEEP_TIME);
> +
> +		if (signal_pending(current)) {
> +			ret = -ERESTARTSYS;
> +			goto err_out;
> +		}
> +	}
> +
> +	if (ret & ENCLS_FAULT_FLAG) {
> +		if (encls_failed(ret))
> +			ENCLS_WARN(ret, "EINIT");
> +
> +		sgx_encl_destroy(encl);
> +		ret = -EFAULT;
> +	} else if (ret) {
> +		pr_debug("EINIT returned %d\n", ret);
> +		ret = -EPERM;
> +	} else {
> +		atomic_or(SGX_ENCL_INITIALIZED, &encl->flags);
> +	}
> +
> +err_out:
> +	mutex_unlock(&encl->lock);
> +	return ret;
> +}
> +
> +/**
> + * sgx_ioc_enclave_init - handler for %SGX_IOC_ENCLAVE_INIT
> + *
> + * @filep:	open file to /dev/sgx

Aaand again:

"@encl:       pointer to an enclave instance (via ioctl() file pointer)"

this is also from a previous review.

> + * @arg:	userspace pointer to a struct sgx_enclave_init instance
> + *
> + * Flush any outstanding enqueued EADD operations and perform EINIT.  The
> + * Launch Enclave Public Key Hash MSRs are rewritten as necessary to match
> + * the enclave's MRSIGNER, which is caculated from the provided sigstruct.
> + *
> + * Return:
> + *   0 on success,
> + *   SGX error code on EINIT failure,
> + *   -errno otherwise
> + */
> +static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
> +{

...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-15 11:28 ` [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation Jarkko Sakkinen
@ 2020-09-21 18:07   ` Borislav Petkov
  2020-09-21 19:27     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 18:07 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:33PM +0300, Jarkko Sakkinen wrote:
> @@ -181,5 +192,12 @@ int __init sgx_drv_init(void)
>  		return ret;
>  	}
>  
> +	ret = misc_register(&sgx_dev_provision);
> +	if (ret) {
> +		pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
> +		misc_deregister(&sgx_dev_enclave);

The comment over misc_deregister() says:

 *      Unregister a miscellaneous device that was previously
 *      successfully registered with misc_register().

but this is not a successful registration here, in the if (ret) case...

> +		return ret;
> +	}
> +
>  	return 0;
>  }
> diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
> index e4063923115b..72747d01c046 100644
> --- a/arch/x86/kernel/cpu/sgx/driver.h
> +++ b/arch/x86/kernel/cpu/sgx/driver.h
> @@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask;
>  extern u64 sgx_xfrm_reserved_mask;
>  extern u32 sgx_xsave_size_tbl[64];
>  
> +extern const struct file_operations sgx_provision_fops;
> +
>  long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
>  
>  int sgx_drv_init(void);
> diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
> index de2ed4f35ffb..4227bca7b477 100644
> --- a/arch/x86/kernel/cpu/sgx/ioctl.c
> +++ b/arch/x86/kernel/cpu/sgx/ioctl.c
> @@ -673,6 +673,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
>  	return ret;
>  }
>  
> +/**
> + * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
> + * @filep:	open file to /dev/sgx
       ^^^^^^

Can you guess what my comment to that would be...?

> + * @arg:	userspace pointer to a struct sgx_enclave_provision instance
> + *
> + * Mark the enclave as being allowed to access a restricted attribute bit.
> + * The requested attribute is specified via the attribute_fd field in the
> + * provided struct sgx_enclave_provision.  The attribute_fd must be a
> + * handle to an SGX attribute file, e.g. "/dev/sgx/provision".
> + *
> + * Failure to explicitly request access to a restricted attribute will cause
> + * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
> + * is access to the PROVISION_KEY.
> + *
> + * Note, access to the EINITTOKEN_KEY is disallowed entirely.
> + *
> + * Return: 0 on success, -errno otherwise
> + */
> +static long sgx_ioc_enclave_provision(struct sgx_encl *encl,
> +					  void __user *arg)

No need for the line break: both function args can fit on the same line.

...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-21 17:35   ` Borislav Petkov
@ 2020-09-21 18:10     ` Sean Christopherson
  2020-09-21 18:27       ` Borislav Petkov
  2020-09-21 19:22       ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-21 18:10 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, Jethro Beekman,
	Haitao Huang, Chunyang Hui, Jordan Hand, Nathaniel McCallum,
	Seth Moore, Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 07:35:14PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:32PM +0300, Jarkko Sakkinen wrote:
> > +static int sgx_einit(struct sgx_sigstruct *sigstruct, void *token,
> > +		     struct sgx_epc_page *secs, u64 *lepubkeyhash)
> > +{
> > +	int ret;
> > +
> > +	preempt_disable();
> > +	sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);
> 
> So this will update the cached copies *and* the MSRs itself if what's
> cached is stale...
> 
> > +	ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
> > +	if (ret == SGX_INVALID_EINITTOKEN) {
> 
> ... so why would it return this error here?
> 
> Definition of this error says:
> 
>  * %SGX_INVALID_EINITTOKEN:     EINITTOKEN is invalid and enclave signer's
>  *                              public key does not match IA32_SGXLEPUBKEYHASH.
> 
> when you just updated them?!
> 
> > +		sgx_update_lepubkeyhash_msrs(lepubkeyhash, true);
> 
> So why force a second time?

The LE pubkey hash MSRs are special snowflakes.  They get reset to Intel's
default key on any loss of EPC, e.g. if the system does a suspend/resume
cycle.  The approach we took (obviously) is to assume the kernel's cache can
be stale at any given time.  The alternative would be to try and track loss
of EPC conditions and emulate the reset, but that's a bit dicey on bare
metal as any missed case would hose SGX, and in a VM it's theoretically
impossible to handle as a particularly unhelpful VMM could emulate loss of
EPC at will.

Yes, this need a big fat comment.

> > +		ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
> > +	}
> > +	preempt_enable();
> > +	return ret;
> > +}

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-21 18:10     ` Sean Christopherson
@ 2020-09-21 18:27       ` Borislav Petkov
       [not found]         ` <20200921191658.GA24823@linux.intel.com>
  2020-09-21 19:22       ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 18:27 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, Jethro Beekman,
	Haitao Huang, Chunyang Hui, Jordan Hand, Nathaniel McCallum,
	Seth Moore, Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 11:10:21AM -0700, Sean Christopherson wrote:
> The LE pubkey hash MSRs are special snowflakes.  They get reset to Intel's
> default key on any loss of EPC, e.g. if the system does a suspend/resume
> cycle.  The approach we took (obviously) is to assume the kernel's cache can
> be stale at any given time.  The alternative would be to try and track loss
> of EPC conditions and emulate the reset, but that's a bit dicey on bare
> metal as any missed case would hose SGX, and in a VM it's theoretically
> impossible to handle as a particularly unhelpful VMM could emulate loss of
> EPC at will.

Lemme try to understand this: the system could suspend/resume right
here:

        sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);

<--- suspend/resume

        ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));

and thus the MSRs would have the default key so you'd need the second
__einit() call?

But what happens if the system suspends before the second __einit()
call?

Why don't you simply drop that @enforce param and let the caller handle
any retries?

Or is the scenario something different?

Or you could perhaps disable suspend/resume around it, maybe something
like lock_system_sleep() or so, from a quick grep...

> Yes, this need a big fat comment.

Oh yeah.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-21 18:10     ` Sean Christopherson
  2020-09-21 18:27       ` Borislav Petkov
@ 2020-09-21 19:22       ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 19:22 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, Jethro Beekman,
	Haitao Huang, Chunyang Hui, Jordan Hand, Nathaniel McCallum,
	Seth Moore, Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 11:10:21AM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2020 at 07:35:14PM +0200, Borislav Petkov wrote:
> > On Tue, Sep 15, 2020 at 02:28:32PM +0300, Jarkko Sakkinen wrote:
> > > +static int sgx_einit(struct sgx_sigstruct *sigstruct, void *token,
> > > +		     struct sgx_epc_page *secs, u64 *lepubkeyhash)
> > > +{
> > > +	int ret;
> > > +
> > > +	preempt_disable();
> > > +	sgx_update_lepubkeyhash_msrs(lepubkeyhash, false);
> > 
> > So this will update the cached copies *and* the MSRs itself if what's
> > cached is stale...
> > 
> > > +	ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
> > > +	if (ret == SGX_INVALID_EINITTOKEN) {
> > 
> > ... so why would it return this error here?
> > 
> > Definition of this error says:
> > 
> >  * %SGX_INVALID_EINITTOKEN:     EINITTOKEN is invalid and enclave signer's
> >  *                              public key does not match IA32_SGXLEPUBKEYHASH.
> > 
> > when you just updated them?!
> > 
> > > +		sgx_update_lepubkeyhash_msrs(lepubkeyhash, true);
> > 
> > So why force a second time?
> 
> The LE pubkey hash MSRs are special snowflakes.  They get reset to Intel's
> default key on any loss of EPC, e.g. if the system does a suspend/resume
> cycle.  The approach we took (obviously) is to assume the kernel's cache can
> be stale at any given time.  The alternative would be to try and track loss
> of EPC conditions and emulate the reset, but that's a bit dicey on bare
> metal as any missed case would hose SGX, and in a VM it's theoretically
> impossible to handle as a particularly unhelpful VMM could emulate loss of
> EPC at will.
> 
> Yes, this need a big fat comment.

Thanks, please provide one :-)

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-21 18:07   ` Borislav Petkov
@ 2020-09-21 19:27     ` Jarkko Sakkinen
  2020-09-21 19:41       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 19:27 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Mon, Sep 21, 2020 at 08:07:28PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:33PM +0300, Jarkko Sakkinen wrote:
> > @@ -181,5 +192,12 @@ int __init sgx_drv_init(void)
> >  		return ret;
> >  	}
> >  
> > +	ret = misc_register(&sgx_dev_provision);
> > +	if (ret) {
> > +		pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
> > +		misc_deregister(&sgx_dev_enclave);
> 
> The comment over misc_deregister() says:
> 
>  *      Unregister a miscellaneous device that was previously
>  *      successfully registered with misc_register().
> 
> but this is not a successful registration here, in the if (ret) case...

'sgx_dev_enclave' is successfully register whenever that happens. Am I
missing something here?

> > + * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
> > + * @filep:	open file to /dev/sgx
>        ^^^^^^
> 
> Can you guess what my comment to that would be...?

There is also another incosistency that I fixed: the first line should
have 'sgx_ioc_enclave_provision'.

> > +static long sgx_ioc_enclave_provision(struct sgx_encl *encl,
> > +					  void __user *arg)
> 
> No need for the line break: both function args can fit on the same line.

Fixed this one too, thanks.

> 
> ...
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-21 13:51       ` Borislav Petkov
@ 2020-09-21 19:29         ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 19:29 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Sean Christopherson, Suresh Siddha, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 03:51:07PM +0200, Borislav Petkov wrote:
> > "... after checking that the provided data for SECS meets the expectations
> > of ENCLS[ECREATE] for an unitialized enclave and size of the address

There is a typo (should be uninitialized).

> > Is this sufficient for you, or do you have further suggestions?
> 
> Yes, no further suggestions.
> 
> Thx.


Great, thank you.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-21 19:27     ` Jarkko Sakkinen
@ 2020-09-21 19:41       ` Borislav Petkov
  2020-09-21 21:26         ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-21 19:41 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Mon, Sep 21, 2020 at 10:27:06PM +0300, Jarkko Sakkinen wrote:
> 'sgx_dev_enclave' is successfully register whenever that happens. Am I
> missing something here?

No, I was missing the fact that you have *two* misc devices and you're
deregistering the first one in the error path of the second.

Forget what I said. ;-\

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
       [not found]         ` <20200921165758.GA24156@linux.intel.com>
@ 2020-09-21 21:07           ` Jarkko Sakkinen
  2020-09-21 21:18             ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 21:07 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > option of adding enclave specific LSM policies in the future.
> > > 
> > > The source file (if one exists) for the enclave is long gone when the enclave
> > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > permissions for a given page are snapshotted when the page is added to the
> > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > noexec file system.
> > 
> > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > addresses, checks that permissions are not surpassed and there are
> > no holes.
> 
> Yes, that's what I said.

sgx_encl_add_page() will remove such page. The callback does not
interact with this process as such pages never get to the enclave.

> I would copy-paste the part of the response that was snipped...

I do agree with the main conclusions but it contains also things that I
do not see relating that much, like noexec partitions. It goes too far
in detail what will LSM's end up doing. I absolutely do not want to
forecast too far how LSM hooks would work.

Since we do not have ioctl's for EMODPE and such, I see EMODPE as the
only reason for doing this right now. Otherwise, we are in trouble with
any possible LSM callbacks. For any sort of access control decision,
things decided must stick.

I would add something like this to the commit message largely based on
your text:

"SGX stores the permissions for each page when they are first added, and
will implement this callback to check that mmap() or mprotect() does not
surpass these permissions in the requested address range.

This is done to prevent using EMODPE upgrading permissions of a page
after mmap() or mprotect() has been done, which would prevent any sort
of LSM callbacks to be implemented later on because the access control
decision could deprecate."

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-21 21:07           ` Jarkko Sakkinen
@ 2020-09-21 21:18             ` Sean Christopherson
  2020-09-22  5:29               ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-21 21:18 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > option of adding enclave specific LSM policies in the future.
> > > > 
> > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > permissions for a given page are snapshotted when the page is added to the
> > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > noexec file system.
> > > 
> > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > addresses, checks that permissions are not surpassed and there are
> > > no holes.
> > 
> > Yes, that's what I said.
> 
> sgx_encl_add_page() will remove such page. The callback does not
> interact with this process as such pages never get to the enclave.

I think we're in violent agreement, mostly.

Userspace can add the page without EXEC permissions in the EPCM, and thus
avoid the noexec/VM_MAYEXEC check.  The enclave can then do EMODPE to gain
EXEC permissions in the EPMC.  Without the ->mprotect() hook, we wouldn't
be able to detect/prevent such shenanigans.

> > I would copy-paste the part of the response that was snipped...
> 
> I do agree with the main conclusions but it contains also things that I
> do not see relating that much, like noexec partitions.

As above, this does directly related to noexec/VM_MAYEXEC.

> It goes too far in detail what will LSM's end up doing. I absolutely do not
> want to forecast too far how LSM hooks would work.

That's fine, I was responding to Andy's question, not intending to write a
changelog.
 
> Since we do not have ioctl's for EMODPE and such, I see EMODPE as the
> only reason for doing this right now. Otherwise, we are in trouble with
> any possible LSM callbacks. For any sort of access control decision,
> things decided must stick.

Yes, again, violent agreement :-).

> I would add something like this to the commit message largely based on
> your text:
> 
> "SGX stores the permissions for each page when they are first added, and
> will implement this callback to check that mmap() or mprotect() does not
> surpass these permissions in the requested address range.
> 
> This is done to prevent using EMODPE upgrading permissions of a page
> after mmap() or mprotect() has been done, which would prevent any sort
> of LSM callbacks to be implemented later on because the access control
> decision could deprecate."

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-21 19:41       ` Borislav Petkov
@ 2020-09-21 21:26         ` Jarkko Sakkinen
  2020-09-22  8:30           ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-21 21:26 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Mon, Sep 21, 2020 at 09:41:56PM +0200, Borislav Petkov wrote:
> On Mon, Sep 21, 2020 at 10:27:06PM +0300, Jarkko Sakkinen wrote:
> > 'sgx_dev_enclave' is successfully register whenever that happens. Am I
> > missing something here?
> 
> No, I was missing the fact that you have *two* misc devices and you're
> deregistering the first one in the error path of the second.
> 
> Forget what I said. ;-\

Ok, great.

BTW, probably would make sense to rewrite the short summary as:

"x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION"

for the sake of consistency with the three precursoring patches.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-21 21:18             ` Sean Christopherson
@ 2020-09-22  5:29               ` Jarkko Sakkinen
  2020-09-22  5:35                 ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-22  5:29 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > > option of adding enclave specific LSM policies in the future.
> > > > > 
> > > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > > permissions for a given page are snapshotted when the page is added to the
> > > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > > noexec file system.
> > > > 
> > > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > > addresses, checks that permissions are not surpassed and there are
> > > > no holes.
> > > 
> > > Yes, that's what I said.
> > 
> > sgx_encl_add_page() will remove such page. The callback does not
> > interact with this process as such pages never get to the enclave.
> 
> I think we're in violent agreement, mostly.
> 
> Userspace can add the page without EXEC permissions in the EPCM, and thus
> avoid the noexec/VM_MAYEXEC check.  The enclave can then do EMODPE to gain
> EXEC permissions in the EPMC.  Without the ->mprotect() hook, we wouldn't
> be able to detect/prevent such shenanigans.

Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.

I'm only wondering why not block noexec completely with any permissions,
i.e. why not just have unconditional VM_MAYEXEC check?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22  5:29               ` Jarkko Sakkinen
@ 2020-09-22  5:35                 ` Jarkko Sakkinen
  2020-09-22 16:43                   ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-22  5:35 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > > > option of adding enclave specific LSM policies in the future.
> > > > > > 
> > > > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > > > permissions for a given page are snapshotted when the page is added to the
> > > > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > > > noexec file system.
> > > > > 
> > > > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > > > addresses, checks that permissions are not surpassed and there are
> > > > > no holes.
> > > > 
> > > > Yes, that's what I said.
> > > 
> > > sgx_encl_add_page() will remove such page. The callback does not
> > > interact with this process as such pages never get to the enclave.
> > 
> > I think we're in violent agreement, mostly.
> > 
> > Userspace can add the page without EXEC permissions in the EPCM, and thus
> > avoid the noexec/VM_MAYEXEC check.  The enclave can then do EMODPE to gain
> > EXEC permissions in the EPMC.  Without the ->mprotect() hook, we wouldn't
> > be able to detect/prevent such shenanigans.
> 
> Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
> 
> I'm only wondering why not block noexec completely with any permissions,
> i.e. why not just have unconditional VM_MAYEXEC check?

I.e. why not this:

static int __sgx_encl_add_page(struct sgx_encl *encl,
			       struct sgx_encl_page *encl_page,
			       struct sgx_epc_page *epc_page,
			       struct sgx_secinfo *secinfo, unsigned long src)
{
	struct sgx_pageinfo pginfo;
	struct vm_area_struct *vma;
	struct page *src_page;
	int ret;

	vma = find_vma(current->mm, src);
	if (!vma)
		return -EFAULT;

	if (!(vma->vm_flags & VM_MAYEXEC))
		return -EACCES;

I'm not seeing the reason for "partial support" for noexec partitions.

If there is a good reason, fine, let's just then document it.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
       [not found]         ` <20200921191658.GA24823@linux.intel.com>
@ 2020-09-22  8:29           ` Borislav Petkov
  2020-09-22 11:50             ` Jarkko Sakkinen
  2020-09-22 12:56             ` Jethro Beekman
  0 siblings, 2 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22  8:29 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, Jethro Beekman,
	Haitao Huang, Chunyang Hui, Jordan Hand, Nathaniel McCallum,
	Seth Moore, Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Mon, Sep 21, 2020 at 12:17:00PM -0700, Sean Christopherson wrote:
> That was effectively my original suggestion as well, check for a stale cache
> and retry indefinitely.  I capitulated because it did feel like I was being
> overly paranoid.  I'm obviously ok going the retry indefinitely route :-).
> 
> https://lkml.kernel.org/r/20180904163546.GA5421@linux.intel.com

Right, so if EINIT is so expensive, why does it matter how many cyccles
WRMSR has? I.e., you don't really need to cache - you simply write the 4
MSRs and you're done. Simple.

As to "indefinitely" - caller can increment a counter which counts
how many times it returned SGX_INVALID_EINITTOKEN. I guess when it
reaches some too high number which should not be reached during normal
usage patterns, you can give up and issue a message to say that counter
reached max retries or so but other than that, you should be ok. That
thing is running interruptible in a loop anyway...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
  2020-09-21 21:26         ` Jarkko Sakkinen
@ 2020-09-22  8:30           ` Borislav Petkov
  0 siblings, 0 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22  8:30 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-security-module,
	Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Tue, Sep 22, 2020 at 12:26:38AM +0300, Jarkko Sakkinen wrote:
> BTW, probably would make sense to rewrite the short summary as:
> 
> "x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION"
> 
> for the sake of consistency with the three precursoring patches.

Ok.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-15 11:28 ` [PATCH v38 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
@ 2020-09-22 10:45   ` Borislav Petkov
  2020-09-22 14:03     ` Jarkko Sakkinen
  2020-09-22 16:24     ` Sean Christopherson
  0 siblings, 2 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22 10:45 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-mm, Jethro Beekman,
	Jordan Hand, Nathaniel McCallum, Chunyang Hui, Seth Moore,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:34PM +0300, Jarkko Sakkinen wrote:
> There is a limited amount of EPC available. Therefore, some of it must be
> copied to the regular memory, and only subset kept in the SGX reserved
> memory. While kernel cannot directly access enclave memory, SGX provides a
> set of ENCLS leaf functions to perform reclaiming.
> 
> This commits implements a page reclaimer by using these leaf functions. It

s/This commits implements/Implement/

> picks the victim pages in LRU fashion from all the enclaves running in the
> system. The thread ksgxswapd reclaims pages on the event when the number of
> free EPC pages goes below SGX_NR_LOW_PAGES up until it reaches
> SGX_NR_HIGH_PAGES.

...

Had to grep the SDM for that "eldu" magic. It could use a comment:

/*
 * ELDU: Load an EPC page as unblocked. For more info, see "OS
 * Management of EPC Pages" in the SDM.
 */

or so, to denote what's going on here.

> +static struct sgx_epc_page *sgx_encl_eldu(struct sgx_encl_page *encl_page,
> +					  struct sgx_epc_page *secs_page)
> +{
> +	unsigned long va_offset = SGX_ENCL_PAGE_VA_OFFSET(encl_page);
> +	struct sgx_encl *encl = encl_page->encl;
> +	struct sgx_epc_page *epc_page;
> +	int ret;
> +
> +	epc_page = sgx_alloc_epc_page(encl_page, false);
> +	if (IS_ERR(epc_page))
> +		return epc_page;
> +
> +	ret = __sgx_encl_eldu(encl_page, epc_page, secs_page);
> +	if (ret) {
> +		sgx_free_epc_page(epc_page);
> +		return ERR_PTR(ret);
> +	}
> +
> +	sgx_free_va_slot(encl_page->va_page, va_offset);
> +	list_move(&encl_page->va_page->list, &encl->va_pages);
> +	encl_page->desc &= ~SGX_ENCL_PAGE_VA_OFFSET_MASK;
> +	encl_page->epc_page = epc_page;
> +
> +	return epc_page;
> +}

...

> diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
> index 0448d22d3010..11dcf4e7fb3e 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -19,6 +19,10 @@
>  
>  /**
>   * enum sgx_encl_page_desc - defines bits for an enclave page's descriptor
> + * %SGX_ENCL_PAGE_RECLAIMED:		The page is in the process of being
> + *					reclaimed.

SGX_ENCL_PAGE_RECLAIMED means, tho, that the page has been reclaimed
already.

I guess that reads better:

+		if (entry->desc & SGX_ENCL_PAGE_BEING_RECLAIMED)
+			return ERR_PTR(-EBUSY);


> + * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
> + *					(VA) page for a swapped page.
>   * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
>   *
>   * The page address for SECS is zero and is used by the subsystem to recognize

...

> @@ -86,24 +123,34 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
>  {
>  	unsigned long encl_size = secs->size + PAGE_SIZE;
>  	struct sgx_epc_page *secs_epc;
> +	struct sgx_va_page *va_page;
>  	struct sgx_pageinfo pginfo;
>  	struct sgx_secinfo secinfo;
>  	struct file *backing;
>  	long ret;
>  
> +	va_page = sgx_encl_grow(encl);
> +	if (IS_ERR(va_page))
> +		return PTR_ERR(va_page);
> +	else if (va_page)

Not "else" simply?

AFAICT, sgx_encl_grow() would either return an ERR_PTR or the actual
page...

Also, should the growing happen *after* the SECS validation?

> +		list_add(&va_page->list, &encl->va_pages);
> +
>  	if (sgx_validate_secs(secs)) {
>  		pr_debug("invalid SECS\n");
> -		return -EINVAL;
> +		ret = -EINVAL;
> +		goto err_out_shrink;
>  	}
>  
>  	backing = shmem_file_setup("SGX backing", encl_size + (encl_size >> 5),
>  				   VM_NORESERVE);
> -	if (IS_ERR(backing))
> -		return PTR_ERR(backing);
> +	if (IS_ERR(backing)) {
> +		ret = PTR_ERR(backing);
> +		goto err_out_shrink;
> +	}
>  
>  	encl->backing = backing;
>  
> -	secs_epc = __sgx_alloc_epc_page();
> +	secs_epc = sgx_alloc_epc_page(&encl->secs, true);
>  	if (IS_ERR(secs_epc)) {
>  		ret = PTR_ERR(secs_epc);
>  		goto err_out_backing;
> @@ -151,6 +198,9 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
>  	fput(encl->backing);
>  	encl->backing = NULL;
>  
> +err_out_shrink:
> +	sgx_encl_shrink(encl, va_page);
> +
>  	return ret;
>  }

...


Let's add some comment blurb about "Write back/invalidate an EPC page"
to at least start to explain what that "ewb" is.

> +static void sgx_encl_ewb(struct sgx_epc_page *epc_page,
> +			 struct sgx_backing *backing)
> +{
> +	struct sgx_encl_page *encl_page = epc_page->owner;
> +	struct sgx_encl *encl = encl_page->encl;
> +	struct sgx_va_page *va_page;
> +	unsigned int va_offset;
> +	void *va_slot;
> +	int ret;
> +
> +	encl_page->desc &= ~SGX_ENCL_PAGE_RECLAIMED;
> +
> +	va_page = list_first_entry(&encl->va_pages, struct sgx_va_page,
> +				   list);
> +	va_offset = sgx_alloc_va_slot(va_page);
> +	va_slot = sgx_get_epc_addr(va_page->epc_page) + va_offset;
> +	if (sgx_va_page_full(va_page))
> +		list_move_tail(&va_page->list, &encl->va_pages);
> +
> +	ret = __sgx_encl_ewb(epc_page, va_slot, backing);
> +	if (ret == SGX_NOT_TRACKED) {
> +		ret = __etrack(sgx_get_epc_addr(encl->secs.epc_page));
> +		if (ret) {
> +			if (encls_failed(ret))
> +				ENCLS_WARN(ret, "ETRACK");
> +		}
> +
> +		ret = __sgx_encl_ewb(epc_page, va_slot, backing);
> +		if (ret == SGX_NOT_TRACKED) {
> +			/*
> +			 * Slow path, send IPIs to kick cpus out of the
> +			 * enclave.  Note, it's imperative that the cpu
> +			 * mask is generated *after* ETRACK, else we'll
> +			 * miss cpus that entered the enclave between
> +			 * generating the mask and incrementing epoch.
> +			 */
> +			on_each_cpu_mask(sgx_encl_ewb_cpumask(encl),
> +					 sgx_ipi_cb, NULL, 1);
> +			ret = __sgx_encl_ewb(epc_page, va_slot, backing);
> +		}
> +	}
> +
> +	if (ret) {
> +		if (encls_failed(ret))
> +			ENCLS_WARN(ret, "EWB");
> +
> +		sgx_free_va_slot(va_page, va_offset);
> +	} else {
> +		encl_page->desc |= va_offset;
> +		encl_page->va_page = va_page;
> +	}

...

> +static void sgx_reclaim_pages(void)
> +{
> +	struct sgx_epc_page *chunk[SGX_NR_TO_SCAN];
> +	struct sgx_backing backing[SGX_NR_TO_SCAN];
> +	struct sgx_epc_section *section;
> +	struct sgx_encl_page *encl_page;
> +	struct sgx_epc_page *epc_page;
> +	int cnt = 0;
> +	int ret;
> +	int i;
> +
> +	spin_lock(&sgx_active_page_list_lock);
> +	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> +		if (list_empty(&sgx_active_page_list))

Isn't it enough to do this once, i.e., not in the loop? You're holding
sgx_active_page_list_lock...

> +			break;
> +
> +		epc_page = list_first_entry(&sgx_active_page_list,
> +					    struct sgx_epc_page, list);
> +		list_del_init(&epc_page->list);
> +		encl_page = epc_page->owner;
> +
> +		if (kref_get_unless_zero(&encl_page->encl->refcount) != 0)
> +			chunk[cnt++] = epc_page;
> +		else
> +			/* The owner is freeing the page. No need to add the
> +			 * page back to the list of reclaimable pages.
> +			 */
> +			epc_page->desc &= ~SGX_EPC_PAGE_RECLAIMABLE;
> +	}
> +	spin_unlock(&sgx_active_page_list_lock);
> +
> +	for (i = 0; i < cnt; i++) {
> +		epc_page = chunk[i];
> +		encl_page = epc_page->owner;
> +
> +		if (!sgx_reclaimer_age(epc_page))
> +			goto skip;
> +
> +		ret = sgx_encl_get_backing(encl_page->encl,
> +					   SGX_ENCL_PAGE_INDEX(encl_page),
> +					   &backing[i]);
> +		if (ret)
> +			goto skip;
> +
> +		mutex_lock(&encl_page->encl->lock);
> +		encl_page->desc |= SGX_ENCL_PAGE_RECLAIMED;
> +		mutex_unlock(&encl_page->encl->lock);
> +		continue;
> +
> +skip:
> +		spin_lock(&sgx_active_page_list_lock);
> +		list_add_tail(&epc_page->list, &sgx_active_page_list);
> +		spin_unlock(&sgx_active_page_list_lock);
> +
> +		kref_put(&encl_page->encl->refcount, sgx_encl_release);
> +
> +		chunk[i] = NULL;
> +	}
> +
> +	for (i = 0; i < cnt; i++) {
> +		epc_page = chunk[i];
> +		if (epc_page)
> +			sgx_reclaimer_block(epc_page);
> +	}
> +
> +	for (i = 0; i < cnt; i++) {
> +		epc_page = chunk[i];
> +		if (!epc_page)
> +			continue;
> +
> +		encl_page = epc_page->owner;
> +		sgx_reclaimer_write(epc_page, &backing[i]);
> +		sgx_encl_put_backing(&backing[i], true);
> +
> +		kref_put(&encl_page->encl->refcount, sgx_encl_release);
> +		epc_page->desc &= ~SGX_EPC_PAGE_RECLAIMABLE;
> +
> +		section = sgx_get_epc_section(epc_page);
> +		spin_lock(&section->lock);
> +		list_add_tail(&epc_page->list, &section->page_list);
> +		section->free_cnt++;
> +		spin_unlock(&section->lock);
> +	}
> +}
> +
>  
>  static void sgx_sanitize_section(struct sgx_epc_section *section)

...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-22  8:29           ` Borislav Petkov
@ 2020-09-22 11:50             ` Jarkko Sakkinen
  2020-09-22 12:56             ` Jethro Beekman
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-22 11:50 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Sean Christopherson, x86, linux-sgx, linux-kernel,
	Jethro Beekman, Haitao Huang, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny, Suresh Siddha,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 10:29:18AM +0200, Borislav Petkov wrote:
> On Mon, Sep 21, 2020 at 12:17:00PM -0700, Sean Christopherson wrote:
> > That was effectively my original suggestion as well, check for a stale cache
> > and retry indefinitely.  I capitulated because it did feel like I was being
> > overly paranoid.  I'm obviously ok going the retry indefinitely route :-).
> > 
> > https://lkml.kernel.org/r/20180904163546.GA5421@linux.intel.com
> 
> Right, so if EINIT is so expensive, why does it matter how many cyccles
> WRMSR has? I.e., you don't really need to cache - you simply write the 4
> MSRs and you're done. Simple.
> 
> As to "indefinitely" - caller can increment a counter which counts
> how many times it returned SGX_INVALID_EINITTOKEN. I guess when it
> reaches some too high number which should not be reached during normal
> usage patterns, you can give up and issue a message to say that counter
> reached max retries or so but other than that, you should be ok. That
> thing is running interruptible in a loop anyway...

The way I see it after reading the thread is:

1. Start with simpler always-update-MSRs in this patch set.
2. If this ever causes a bottleneck, then we will fix it.

> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-22  8:29           ` Borislav Petkov
  2020-09-22 11:50             ` Jarkko Sakkinen
@ 2020-09-22 12:56             ` Jethro Beekman
  2020-09-22 14:29               ` Borislav Petkov
  2020-09-22 16:29               ` Sean Christopherson
  1 sibling, 2 replies; 180+ messages in thread
From: Jethro Beekman @ 2020-09-22 12:56 UTC (permalink / raw)
  To: Borislav Petkov, Sean Christopherson
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx


[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On 2020-09-22 10:29, Borislav Petkov wrote:
> On Mon, Sep 21, 2020 at 12:17:00PM -0700, Sean Christopherson wrote:
>> That was effectively my original suggestion as well, check for a stale cache
>> and retry indefinitely.  I capitulated because it did feel like I was being
>> overly paranoid.  I'm obviously ok going the retry indefinitely route :-).
>>
>> https://lkml.kernel.org/r/20180904163546.GA5421@linux.intel.com
> 
> Right, so if EINIT is so expensive, why does it matter how many cyccles
> WRMSR has? I.e., you don't really need to cache - you simply write the 4
> MSRs and you're done. Simple.
> 
> As to "indefinitely" - caller can increment a counter which counts
> how many times it returned SGX_INVALID_EINITTOKEN. I guess when it
> reaches some too high number which should not be reached during normal
> usage patterns, you can give up and issue a message to say that counter
> reached max retries or so but other than that, you should be ok. That
> thing is running interruptible in a loop anyway...

I don't see why you'd need to retry indefinitely. Yes the MSRs may not match the cached value for “reasons”, but if after you've written them once it still doesn't work, clearly either 1) an “unhelpful” VMM is actively messing with the MSRs which I'd say is at best a VMM bug or 2) there was an EPC reset and your enclave is now invalid anyway, so no need to EINIT.

--
Jethro Beekman | Fortanix


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 10:45   ` Borislav Petkov
@ 2020-09-22 14:03     ` Jarkko Sakkinen
  2020-09-22 14:24       ` Borislav Petkov
  2020-09-29  1:14       ` Sean Christopherson
  2020-09-22 16:24     ` Sean Christopherson
  1 sibling, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-22 14:03 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-mm, Jethro Beekman,
	Jordan Hand, Nathaniel McCallum, Chunyang Hui, Seth Moore,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
> > + *					(VA) page for a swapped page.
> >   * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
> >   *
> >   * The page address for SECS is zero and is used by the subsystem to recognize
> 
> ...

So what's wrong over here?

> > @@ -86,24 +123,34 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
> >  {
> >  	unsigned long encl_size = secs->size + PAGE_SIZE;
> >  	struct sgx_epc_page *secs_epc;
> > +	struct sgx_va_page *va_page;
> >  	struct sgx_pageinfo pginfo;
> >  	struct sgx_secinfo secinfo;
> >  	struct file *backing;
> >  	long ret;
> >  
> > +	va_page = sgx_encl_grow(encl);
> > +	if (IS_ERR(va_page))
> > +		return PTR_ERR(va_page);
> > +	else if (va_page)
> 
> Not "else" simply?
> 
> AFAICT, sgx_encl_grow() would either return an ERR_PTR or the actual
> page...
> 
> Also, should the growing happen *after* the SECS validation?

Yes, it would make sense. I'll move it.

> Let's add some comment blurb about "Write back/invalidate an EPC page"
> to at least start to explain what that "ewb" is.

OK, I'll try to write something understandable.

> > +	spin_lock(&sgx_active_page_list_lock);
> > +	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> > +		if (list_empty(&sgx_active_page_list))
> 
> Isn't it enough to do this once, i.e., not in the loop? You're holding
> sgx_active_page_list_lock...

I think that would make sense. Distantly analogous to the EINIT
discussion. Too complex code for yet to be known problem workloads I'd
say.


> >  static void sgx_sanitize_section(struct sgx_epc_section *section)
> 
> ...

Is this about documenting this function?

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Thanks, this was valuable feedback.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 14:03     ` Jarkko Sakkinen
@ 2020-09-22 14:24       ` Borislav Petkov
  2020-09-23 14:52         ` Jarkko Sakkinen
  2020-09-29  1:14       ` Sean Christopherson
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22 14:24 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-mm, Jethro Beekman,
	Jordan Hand, Nathaniel McCallum, Chunyang Hui, Seth Moore,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
> > > + *					(VA) page for a swapped page.
> > >   * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
> > >   *
> > >   * The page address for SECS is zero and is used by the subsystem to recognize
> > 
> > ...
> 
> So what's wrong over here?

Nothing - that's just an ellipsis: https://en.wikipedia.org/wiki/Ellipsis

I do that because otherwise you'd have to scroll through pages of quoted
mail for no good reason and that ain't friendly at all. And I notice
people not trimming their replies and not quoting only the text they
reply to. They should not wonder if their emails remain unread.

Thx for the rest.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-22 12:56             ` Jethro Beekman
@ 2020-09-22 14:29               ` Borislav Petkov
  2020-09-23 14:47                 ` Jarkko Sakkinen
  2020-09-22 16:29               ` Sean Christopherson
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22 14:29 UTC (permalink / raw)
  To: Jethro Beekman
  Cc: Sean Christopherson, Jarkko Sakkinen, x86, linux-sgx,
	linux-kernel, Haitao Huang, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny, Suresh Siddha,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 02:56:19PM +0200, Jethro Beekman wrote:
> I don't see why you'd need to retry indefinitely. Yes the MSRs may not
> match the cached value for “reasons”, but if after you've written
> them once it still doesn't work, clearly either 1) an “unhelpful”
> VMM is actively messing with the MSRs which I'd say is at best a VMM
> bug or 2) there was an EPC reset and your enclave is now invalid
> anyway, so no need to EINIT.

/me likes that even more.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
       [not found]         ` <20200922125801.GA133710@linux.intel.com>
@ 2020-09-22 15:11           ` Dave Hansen
  2020-09-23 13:30             ` Jarkko Sakkinen
                               ` (2 more replies)
  0 siblings, 3 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-22 15:11 UTC (permalink / raw)
  To: Jarkko Sakkinen, Andy Lutomirski
  Cc: Sean Christopherson, Andy Lutomirski, X86 ML, linux-sgx, LKML,
	Linux-MM, Andrew Morton, Matthew Wilcox, Jethro Beekman,
	Darren Kenny, Andy Shevchenko, asapek, Borislav Petkov, Xing,
	Cedric, chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> called enclaves, of which page permissions are defined when the enclave

"of which" => "for which"

> is first loaded. Once an enclave is loaded and initialized, it can be
> mapped to the process address space.

Could you compare and contrast this a *bit* with existing executables?
What's special about SGX?  ELF executables have page permissions inside
the binary too.  Why don't we use this mechanism for them?

> Enclave permissions can be dynamically modified by using ENCLS[EMODPE]

I'm not sure this sentence matters.  I'm not sure why I care what the
instruction is named that does this.  But, it _sounds_ here like an
enclave can adjust its own permissions directly with ENCLS[EMODPE].

> instruction. We want to limit its use to not allow higher permissions than
> the ones defined when the enclave was first created.

Rather than higher and lower, please use stronger and weaker.

Also, please get rid of the "we".

> Add 'mprotect' hook to vm_ops, so that we can implement a callback for SGX
> that will check that {mmap, mprotect}() permissions do not surpass any of
> the page permissions in the address range defined.

"check" => "ensure"

> This is required in order to be able to make any access control decisions
> when enclave pages are loaded.
Now I'm confused.  I actually don't think I have a strong understanding
of how an enclave actually gets loaded, how mmap() and mprotect() are
normally used and what this hook is intended to thwart.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-15 11:28 ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
@ 2020-09-22 15:44   ` Borislav Petkov
  2020-09-23 13:20     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22 15:44 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx


> Subject: Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
			     ... x86/sgx: Add ptrace() support...

subject needs a verb.

On Tue, Sep 15, 2020 at 02:28:35PM +0300, Jarkko Sakkinen wrote:
> Add VMA callbacks for ptrace() that can be used with debug enclaves.
> With debug enclaves data can be read and write the memory word at a time

I think you wanna say here

"... data can be read and/or written a memory word at a time by using..."

> by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.
> 
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  arch/x86/kernel/cpu/sgx/encl.c | 87 ++++++++++++++++++++++++++++++++++
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 11ec2df59b54..7f8df2c8ef35 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -333,10 +333,97 @@ static int sgx_vma_mprotect(struct vm_area_struct *vma,
>  	return mprotect_fixup(vma, pprev, start, end, newflags);
>  }
>  
> +static int sgx_edbgrd(struct sgx_encl *encl, struct sgx_encl_page *page,
> +		      unsigned long addr, void *data)
> +{
> +	unsigned long offset = addr & ~PAGE_MASK;
> +	int ret;
> +
> +
> +	ret = __edbgrd(sgx_get_epc_addr(page->epc_page) + offset, data);
> +	if (ret)
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int sgx_edbgwr(struct sgx_encl *encl, struct sgx_encl_page *page,
> +		      unsigned long addr, void *data)
> +{
> +	unsigned long offset = addr & ~PAGE_MASK;
> +	int ret;
> +
> +	ret = __edbgwr(sgx_get_epc_addr(page->epc_page) + offset, data);
> +	if (ret)
> +		return -EIO;
> +
> +	return 0;
> +}

I know those are supposed to correspond to the ENCLS leafs but the
function names are totally unreadable. I guess you could name them

sgx_encl_dbg_read
sgx_encl_dbg_write

and leave the lowlevel helpers like the insn names.

> +static int sgx_vma_access(struct vm_area_struct *vma, unsigned long addr,
> +			  void *buf, int len, int write)
> +{
> +	struct sgx_encl *encl = vma->vm_private_data;
> +	struct sgx_encl_page *entry = NULL;
> +	char data[sizeof(unsigned long)];
> +	unsigned long align;
> +	unsigned int flags;
> +	int offset;
> +	int cnt;
> +	int ret = 0;
> +	int i;
> +
> +	/* If process was forked, VMA is still there but vm_private_data is set
> +	 * to NULL.
> +	 */

Kernel comments style is:

	/*
	 * A sentence ending with a full-stop.
	 * Another sentence. ...
	 * More sentences. ...
	 */

> +	if (!encl)
> +		return -EFAULT;
> +
> +	flags = atomic_read(&encl->flags);
> +
> +	if (!(flags & SGX_ENCL_DEBUG) || !(flags & SGX_ENCL_INITIALIZED) ||
> +	    (flags & SGX_ENCL_DEAD))
> +		return -EFAULT;
> +
> +	for (i = 0; i < len; i += cnt) {
> +		entry = sgx_encl_reserve_page(encl, (addr + i) & PAGE_MASK);
> +		if (IS_ERR(entry)) {
> +			ret = PTR_ERR(entry);
> +			break;
> +		}
> +
> +		align = ALIGN_DOWN(addr + i, sizeof(unsigned long));
> +		offset = (addr + i) & (sizeof(unsigned long) - 1);
> +		cnt = sizeof(unsigned long) - offset;
> +		cnt = min(cnt, len - i);
> +
> +		ret = sgx_edbgrd(encl, entry, align, data);
> +		if (ret)
> +			goto out;
> +
> +		if (write) {
> +			memcpy(data + offset, buf + i, cnt);
> +			ret = sgx_edbgwr(encl, entry, align, data);
> +			if (ret)
> +				goto out;
> +		} else

		} else {

> +			memcpy(buf + i, data + offset, cnt);

		}

Put the else branch in {} too.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 10:45   ` Borislav Petkov
  2020-09-22 14:03     ` Jarkko Sakkinen
@ 2020-09-22 16:24     ` Sean Christopherson
  2020-09-22 18:02       ` Borislav Petkov
  2020-09-23 15:25       ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-22 16:24 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:34PM +0300, Jarkko Sakkinen wrote:
> > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
> > + *					(VA) page for a swapped page.
> >   * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
> >   *
> >   * The page address for SECS is zero and is used by the subsystem to recognize
> 
> ...
> 
> > @@ -86,24 +123,34 @@ static int sgx_encl_create(struct sgx_encl *encl, struct sgx_secs *secs)
> >  {
> >  	unsigned long encl_size = secs->size + PAGE_SIZE;
> >  	struct sgx_epc_page *secs_epc;
> > +	struct sgx_va_page *va_page;
> >  	struct sgx_pageinfo pginfo;
> >  	struct sgx_secinfo secinfo;
> >  	struct file *backing;
> >  	long ret;
> >  
> > +	va_page = sgx_encl_grow(encl);
> > +	if (IS_ERR(va_page))
> > +		return PTR_ERR(va_page);
> > +	else if (va_page)
> 
> Not "else" simply?
> 
> AFAICT, sgx_encl_grow() would either return an ERR_PTR or the actual
> page...
> 

The "else if" is correct.  Version Array (VA) pages have 512 slots that hold
metadata for evicted EPC pages, i.e. swapping a page out of the EPC requires
a VA slot.  For simplicity (LOL), the approach we are taking for initial
support is to reserve a VA slot when adding a page to the enclave[*].  In most
cases, reserving a slot does not require allocating a new VA page, e.g. to
reserve slots 1-511 of the "current" VA page.   The if-elif is handling the
case where the current VA page is fully reserved and a new one needs to be
allocated. The if handles the error, the elif handles success, i.e.

	if (IS_ERR(va_page)) <- needed a new VA page, allocation failed
		return PTR_ERR(va_page);
	else if (va_page)    <- needed a new VA page, allocation succeeded
		list_add(&va_page->list, &encl->va_pages);
	else
		             <- reused the current VA page

When reusing a VA page, we obviously don't want to readd the page to the list
of va_pages, and the error handling path also shouldn't free the VA page.

> Also, should the growing happen *after* the SECS validation?
> 
> > +		list_add(&va_page->list, &encl->va_pages);
> > +
> >  	if (sgx_validate_secs(secs)) {
> >  		pr_debug("invalid SECS\n");
> > -		return -EINVAL;
> > +		ret = -EINVAL;
> > +		goto err_out_shrink;
> >  	}

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-22 12:56             ` Jethro Beekman
  2020-09-22 14:29               ` Borislav Petkov
@ 2020-09-22 16:29               ` Sean Christopherson
  1 sibling, 0 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-22 16:29 UTC (permalink / raw)
  To: Jethro Beekman
  Cc: Borislav Petkov, Jarkko Sakkinen, x86, linux-sgx, linux-kernel,
	Haitao Huang, Chunyang Hui, Jordan Hand, Nathaniel McCallum,
	Seth Moore, Darren Kenny, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 02:56:19PM +0200, Jethro Beekman wrote:
> On 2020-09-22 10:29, Borislav Petkov wrote:
> > On Mon, Sep 21, 2020 at 12:17:00PM -0700, Sean Christopherson wrote:
> >> That was effectively my original suggestion as well, check for a stale cache
> >> and retry indefinitely.  I capitulated because it did feel like I was being
> >> overly paranoid.  I'm obviously ok going the retry indefinitely route :-).
> >>
> >> https://lkml.kernel.org/r/20180904163546.GA5421@linux.intel.com
> > 
> > Right, so if EINIT is so expensive, why does it matter how many cyccles
> > WRMSR has? I.e., you don't really need to cache - you simply write the 4
> > MSRs and you're done. Simple.

Hmm, true.  The 1200+ cycles to write the hash MSRs (they're 3x slower than
other MSRs) seems scary, but compared to the 60k cycles it really doesn't
matter.

> > As to "indefinitely" - caller can increment a counter which counts
> > how many times it returned SGX_INVALID_EINITTOKEN. I guess when it
> > reaches some too high number which should not be reached during normal
> > usage patterns, you can give up and issue a message to say that counter
> > reached max retries or so but other than that, you should be ok. That
> > thing is running interruptible in a loop anyway...
> 
> I don't see why you'd need to retry indefinitely. Yes the MSRs may not match
> the cached value for “reasons”, but if after you've written them once it
> still doesn't work, clearly either 1) an “unhelpful” VMM is actively messing
> with the MSRs which I'd say is at best a VMM bug or 2) there was an EPC reset
> and your enclave is now invalid anyway, so no need to EINIT.

Ah, also true, I overlooked that an MSR reset would also kill the enclave.

So yeah, this can be simplified to:

	if (SGX_LC) {
		for (i = 0; i < 4; i++)
			wrmsrl(...);
	}
	return __einit(...);

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22  5:35                 ` Jarkko Sakkinen
@ 2020-09-22 16:43                   ` Sean Christopherson
  2020-09-23 13:50                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-22 16:43 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> > > Userspace can add the page without EXEC permissions in the EPCM, and thus
> > > avoid the noexec/VM_MAYEXEC check.  The enclave can then do EMODPE to gain
> > > EXEC permissions in the EPMC.  Without the ->mprotect() hook, we wouldn't
> > > be able to detect/prevent such shenanigans.
> > 
> > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
> > 
> > I'm only wondering why not block noexec completely with any permissions,
> > i.e. why not just have unconditional VM_MAYEXEC check?
> 
> I.e. why not this:
> 
> static int __sgx_encl_add_page(struct sgx_encl *encl,
> 			       struct sgx_encl_page *encl_page,
> 			       struct sgx_epc_page *epc_page,
> 			       struct sgx_secinfo *secinfo, unsigned long src)
> {
> 	struct sgx_pageinfo pginfo;
> 	struct vm_area_struct *vma;
> 	struct page *src_page;
> 	int ret;
> 
> 	vma = find_vma(current->mm, src);
> 	if (!vma)
> 		return -EFAULT;
> 
> 	if (!(vma->vm_flags & VM_MAYEXEC))
> 		return -EACCES;
> 
> I'm not seeing the reason for "partial support" for noexec partitions.
> 
> If there is a good reason, fine, let's just then document it.

There are scenarios I can contrive, e.g. loading an enclave from a noexec
filesystem without having to copy the entire enclave to anon memory, or
loading a data payload from a noexec FS.

They're definitely contrived scenarios, but given that we also want the
->mprotect() hook/behavior for potential LSM interaction, supporting said
contrived scenarios costs is "free".

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 16:24     ` Sean Christopherson
@ 2020-09-22 18:02       ` Borislav Petkov
  2020-09-23 15:25       ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-22 18:02 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 09:24:38AM -0700, Sean Christopherson wrote:
> The "else if" is correct.  Version Array (VA) pages have 512 slots that hold
> metadata for evicted EPC pages, i.e. swapping a page out of the EPC requires
> a VA slot.  For simplicity (LOL),

I'll say.

> the approach we are taking for initial support is to reserve a VA slot
> when adding a page to the enclave[*]. In most cases, reserving a slot
> does not require allocating a new VA page, e.g. to reserve slots 1-511
> of the "current" VA page. The if-elif is handling the case where the
> current VA page is fully reserved and a new one needs to be allocated.
> The if handles the error, the elif handles success, i.e.
> 
> 	if (IS_ERR(va_page)) <- needed a new VA page, allocation failed
> 		return PTR_ERR(va_page);
> 	else if (va_page)    <- needed a new VA page, allocation succeeded
> 		list_add(&va_page->list, &encl->va_pages);
> 	else
> 		             <- reused the current VA page

Aha, in that case va_page will be NULL but you're not using it in that
function later and that current VA page is on encl->va_pages which
others can get from there. Ok, gotcha.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-22 15:44   ` Borislav Petkov
@ 2020-09-23 13:20     ` Jarkko Sakkinen
  2020-09-23 16:17       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 13:20 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Tue, Sep 22, 2020 at 05:44:24PM +0200, Borislav Petkov wrote:
> 
> > Subject: Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
> 			     ... x86/sgx: Add ptrace() support...
> 
> subject needs a verb.
> 
> On Tue, Sep 15, 2020 at 02:28:35PM +0300, Jarkko Sakkinen wrote:
> > Add VMA callbacks for ptrace() that can be used with debug enclaves.
> > With debug enclaves data can be read and write the memory word at a time
> 
> I think you wanna say here
> 
> "... data can be read and/or written a memory word at a time by using..."

I also fixed the other issues but I'll paste here the rewrite that I did
for the commit message:

"
x86/sgx: Add ptrace() support for the SGX driver

Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
called enclaves, which cannot be accessed by default when not executing
inside the enclave. Enclaves can be entered by only using predefined memory
addresses, which are defined the enclave is loaded.

However, enclaves can defined as debug enclaves during the load time. In
debug enclaves data can be read and/or written a memory word at a time by
using by using ENCLS[EDBGRD] and ENCLS[EDBGWR] leaf instructions.

Add 'access' implementation to vm_ops with the help of these functions.
This allows to use ptrace() with debug enclaves.
"

I also think that mm CC would make sense also for this patch.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22 15:11           ` Dave Hansen
@ 2020-09-23 13:30             ` Jarkko Sakkinen
  2020-09-23 13:43             ` Jarkko Sakkinen
  2020-09-23 14:33             ` Jarkko Sakkinen
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 13:30 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andy Lutomirski, Sean Christopherson, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> > Enclave permissions can be dynamically modified by using ENCLS[EMODPE]
> 
> I'm not sure this sentence matters.  I'm not sure why I care what the
> instruction is named that does this.  But, it _sounds_ here like an
> enclave can adjust its own permissions directly with ENCLS[EMODPE].

If there was no EMODPE, I would drop this patch from the patch set. It
is the only reason I keep it. There are no other hard reasons to have
this.

> Now I'm confused.  I actually don't think I have a strong understanding
> of how an enclave actually gets loaded, how mmap() and mprotect() are
> normally used and what this hook is intended to thwart.

Enclave gets loaded with the ioctl API so ATM we rely only on
DAC permissions.

In future you might want to have LSM hooks to improve granularity
in two points:

1. When pages are added using SGX_IOC_ENCLAVE ADD_PAGES.
2. When enclave is initialized using SGX_IOC_ENCLAVE_INIT

In both you might want to make a policy decision based on origin
and page permissions.

If we do not limit mmap(), enclave could later on upgrade its
permissions with EMODPE and do mmap().

No matter what kind of LSM hooks or whatever possible improvements
are done later on to access control, they won't work unless we have
this because the permissions could be different than the original.

With this change you can still do EMODPE inside an enclave, but you
don't gain anything with it because your max permissions are capped
during the build time.

I'm not sure what exactly from this is missing from the commit message
but if you get this explanation maybe you can help me out with that.

Thank you for the feedback.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22 15:11           ` Dave Hansen
  2020-09-23 13:30             ` Jarkko Sakkinen
@ 2020-09-23 13:43             ` Jarkko Sakkinen
  2020-09-23 14:33             ` Jarkko Sakkinen
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 13:43 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andy Lutomirski, Sean Christopherson, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> > called enclaves, of which page permissions are defined when the enclave
> 
> "of which" => "for which"
> 
> > is first loaded. Once an enclave is loaded and initialized, it can be
> > mapped to the process address space.
> 
> Could you compare and contrast this a *bit* with existing executables?
> What's special about SGX?  ELF executables have page permissions inside
> the binary too.  Why don't we use this mechanism for them?

There is no standard file format for enclaves. They are dynamically
built. And the way enclaves are used as part of an app and throwing
container inside enclave differ. A single format would no work too
well for all possible use cases.

I cannot formally prove this of course but it is highly unlikely that
we could ever define such a format. Thus, the security focus is allow
to verify from origin.

And the existing ecosystem around SGX is already too large to suddenly
move to a single format. User base, I guess, is also an argument. This
is not yet mainline code so technically we have zero ABI debt but I
still think this is a valid point because SGX is already widely used.

I'm not really sure what would be the best way to nail this information
to the commit message but I'll try to figure out something before I send
the next version of the patch set.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
  2020-09-15 11:28 ` [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
@ 2020-09-23 13:50   ` Borislav Petkov
  2020-09-24 11:28     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-23 13:50 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-doc, Randy Dunlap,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

This patch must come first in the set so that other reviewers can read
what all this jazz is about first, before exposing them to the gory
details later.

On Tue, Sep 15, 2020 at 02:28:41PM +0300, Jarkko Sakkinen wrote:
> diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> new file mode 100644
> index 000000000000..706a846ae353
> --- /dev/null
> +++ b/Documentation/x86/sgx.rst
> @@ -0,0 +1,200 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +============
> +Architecture
> +============

Only the title of the document should be sandwiched between two lines of

============

as that is what appears in the documentation TOC. As it is right now,it says
"Architecture" but it should say "Software Guard eXtensions (SGX)"

Architecture should follow only with a bottom line as a section name:

Architecture
============

> +
> +*Software Guard eXtensions (SGX)* is a set of instructions that enable ring-3
> +applications to set aside private regions of code and data. These regions are
> +called enclaves. An enclave can be entered to a fixed set of entry points. Only

s / to / at /

> +a CPU running inside the enclave can access its code and data.
> +
> +The support can be determined by
> +
> +	``grep sgx /proc/cpuinfo``
> +
> +Enclave Page Cache
> +==================
> +
> +SGX utilizes an *Enclave Page Cache (EPC)* to store pages that are associated
> +with an enclave. It is contained in a BIOS reserved region of physical memory.

BIOS-reserved

> +Unlike pages used for regular memory, pages can only be accessed outside the
> +enclave for different purposes with the instructions **ENCLS**, **ENCLV** and
> +**ENCLU**.
> +
> +Direct memory accesses to an enclave can be only done by a CPU executing inside
> +the enclave. An enclave can be entered with **ENCLU[EENTER]** to a fixed set of

s / to / at /

> +entry points. However, a CPU executing inside the enclave can do outside memory
> +accesses.
> +
> +Page Types
> +----------
> +
> +**SGX Enclave Control Structure (SECS)**
> +   Enclave's address range, attributes and other global data are defined
> +   by this structure.
> +
> +**Regular (REG)**
> +   Regular EPC pages contain the code and data of an enclave.
> +
> +**Thread Control Structure (TCS)**
> +   Thread Control Structure pages define the entry points to an enclave and
> +   track the execution state of an enclave thread.
> +
> +**Version Array (VA)**
> +   Version Array pages contain 512 slots, each of which can contain a version
> +   number for a page evicted from the EPC.
> +
> +Enclave Page Cache Map
> +----------------------
> +
> +The processor tracks EPC pages via the *Enclave Page Cache Map (EPCM)*.  EPCM
> +contains an entry for each EPC page, which describes the owning enclave, access
> +rights and page type among the other things.
> +
> +The permissions from EPCM is consulted if and only if walking the kernel page

s/ is / are /

> +tables succeeds. The total permissions are thus a conjunction between page table
> +and EPCM permissions.
> +
> +For all intents and purposes the SGX architecture allows the processor to
			       ^
			       ,

> +invalidate all EPCM entries at will, i.e. requires that software be prepared to
> +handle an EPCM fault at any time. The contents of EPC are encrypted with an
> +ephemeral key, which is lost on power transitions.
> +
> +EPC management
> +==============
> +
> +EPC pages do not have ``struct page`` instances. They are IO memory from kernel
> +perspective. The consequence is that they are always mapped as shared memory.
> +Kernel defines ``/dev/sgx/enclave`` that can be mapped as ``MAP_SHARED`` to
> +define the address range for an enclave.
> +
> +EPC Over-subscription
> +=====================
> +
> +When the amount of free EPC pages goes below a low watermark the swapping thread
> +starts reclaiming pages. The pages that do not have the **A** bit set are
> +selected as victim pages.
> +
> +Launch Control
> +==============
> +
> +SGX provides a launch control mechanism. After all enclave pages have been
> +copied, kernel executes **ENCLS[EINIT]**, which initializes the enclave. Only
> +after this the CPU can execute inside the enclave.
> +
> +This leaf function takes an RSA-3072 signature of the enclave measurement and an
> +optional cryptographic token. Linux does not take advantage of launch tokens.
> +The instruction checks that the signature is signed with the key defined in
> +**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the

That '?' wants to be '[0123]' perhaps?

> +enclave is allowed to be executed.
> +
> +MSRs can be configured by the BIOS to be either readable or writable. Linux

"Those MSRs..."

> +supports only writable configuration in order to give full control to the kernel
> +on launch control policy. Readable configuration requires the use of previously
> +mentioned launch tokens.
> +
> +The current kernel implementation supports only writable MSRs.

This sentence is repeated a couple of lines above.

> The launch is
> +performed by setting the MSRs to the hash of the enclave signer's public key.
> +The alternative would be to have *a launch enclave* that would be signed with
> +the key set into MSRs, which would then generate launch tokens for other
> +enclaves. This would only make sense with read-only MSRs, and thus the option
> +has been discarded.
> +
> +Attestation
> +===========
> +
> +Local Attestation
> +-----------------
> +
> +In local attestation an enclave creates a **REPORT** data structure with
		       ^
		       ,

> +**ENCLS[EREPORT]**, which describes the origin of an enclave. In particular, it
> +contains a AES-CMAC of the enclave contents signed with a report key unique to
> +each processor. All enclaves have access to this key.
> +
> +This mechanism can also be used in addition as a communication channel as the
> +**REPORT** data structure includes a 64-byte field for variable information.

...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22 16:43                   ` Sean Christopherson
@ 2020-09-23 13:50                     ` Jarkko Sakkinen
  2020-09-24 19:11                       ` Haitao Huang
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 13:50 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> > > > Userspace can add the page without EXEC permissions in the EPCM, and thus
> > > > avoid the noexec/VM_MAYEXEC check.  The enclave can then do EMODPE to gain
> > > > EXEC permissions in the EPMC.  Without the ->mprotect() hook, we wouldn't
> > > > be able to detect/prevent such shenanigans.
> > > 
> > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
> > > 
> > > I'm only wondering why not block noexec completely with any permissions,
> > > i.e. why not just have unconditional VM_MAYEXEC check?
> > 
> > I.e. why not this:
> > 
> > static int __sgx_encl_add_page(struct sgx_encl *encl,
> > 			       struct sgx_encl_page *encl_page,
> > 			       struct sgx_epc_page *epc_page,
> > 			       struct sgx_secinfo *secinfo, unsigned long src)
> > {
> > 	struct sgx_pageinfo pginfo;
> > 	struct vm_area_struct *vma;
> > 	struct page *src_page;
> > 	int ret;
> > 
> > 	vma = find_vma(current->mm, src);
> > 	if (!vma)
> > 		return -EFAULT;
> > 
> > 	if (!(vma->vm_flags & VM_MAYEXEC))
> > 		return -EACCES;
> > 
> > I'm not seeing the reason for "partial support" for noexec partitions.
> > 
> > If there is a good reason, fine, let's just then document it.
> 
> There are scenarios I can contrive, e.g. loading an enclave from a noexec
> filesystem without having to copy the entire enclave to anon memory, or
> loading a data payload from a noexec FS.
> 
> They're definitely contrived scenarios, but given that we also want the
> ->mprotect() hook/behavior for potential LSM interaction, supporting said
> contrived scenarios costs is "free".

For me this has caused months of confusion and misunderstanding of this
feature. I only recently realized that "oh, right, we invented this".

They are contrived scenarios enough that they should be considered when
the workloads hit.

Either we fully support noexec or not at all. Any "partial" thing is a
two edged sword: it can bring some robustness with the price of
complexity and possible unknown uknown scenarios where they might become
API issue.

I rather think later on how to extend API in some way to enable such
contrivid scenarios rather than worrying about how this could be abused.

The whole SGX is complex beast already so lets not add any extra when
there is no a hard requirement to do so.

I'll categorically deny noexec in the next patch set version.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-22 15:11           ` Dave Hansen
  2020-09-23 13:30             ` Jarkko Sakkinen
  2020-09-23 13:43             ` Jarkko Sakkinen
@ 2020-09-23 14:33             ` Jarkko Sakkinen
  2020-09-24 14:50               ` Dave Hansen
  2 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 14:33 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andy Lutomirski, Sean Christopherson, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> Now I'm confused.  I actually don't think I have a strong understanding
> of how an enclave actually gets loaded, how mmap() and mprotect() are
> normally used and what this hook is intended to thwart.

You saw my other comments. I scraped this together based on your
feedback and my responses:

"
mm: Add 'mprotect' callback to vm_ops

Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
enclaves, for which page permissions are defined when the enclave is first
loaded. Once an enclave is loaded and initialized, it can be mapped to the
process address space.

There is no standard file format for enclaves. They are dynamically built
and the ways how enclaves are deployed differ greatly. For an app you might
want to have a simple static binary, but on the other hand for a container
you might want to dynamically create the whole thing at run-time. Also, the
existing ecosystem for SGX is already large, which would make the task very
hard.

Finally, even if there was a standard format, one would still want a
dynamic way to add pages to the enclave. One big reason for this is that
enclaves have load time defined pages that represent entry points to the
enclave. Each entry point can service one hardware thread at a time and
you might want to run-time parametrize this depending on your environment.

The consequence is that enclaves are best created with an ioctl API and the
access control can be based only to the origin of the source file for the
enclave data, i.e. on VMA file pointer and page permissions. For example,
this could be done with LSM hooks that are triggered in the appropriate
ioctl's and they could make the access control decision based on this
information.

Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
could upgrade its permissions by using EMODPE followed by an appropriate
mprotect() call. This would be completely hidden from the kernel.

Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
that will ensure that {mmap, mprotect}() permissions do not surpass any of
the original page permissions. This feature allows to maintain and refine
sane access control for enclaves.
"

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-22 14:29               ` Borislav Petkov
@ 2020-09-23 14:47                 ` Jarkko Sakkinen
  2020-09-23 15:55                   ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 14:47 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Jethro Beekman, Sean Christopherson, x86, linux-sgx,
	linux-kernel, Haitao Huang, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny, Suresh Siddha,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 04:29:09PM +0200, Borislav Petkov wrote:
> On Tue, Sep 22, 2020 at 02:56:19PM +0200, Jethro Beekman wrote:
> > I don't see why you'd need to retry indefinitely. Yes the MSRs may not
> > match the cached value for “reasons”, but if after you've written
> > them once it still doesn't work, clearly either 1) an “unhelpful”
> > VMM is actively messing with the MSRs which I'd say is at best a VMM
> > bug or 2) there was an EPC reset and your enclave is now invalid
> > anyway, so no need to EINIT.
> 
> /me likes that even more.

OK, so I did not follow this particular discussion in high detail, so
as a sanity check I'll preview my changes.

I'd refine sgx_update_lepubkeyhash_msrs() to:

static void sgx_update_lepubkeyhash_msrs(u64 *lepubkeyhash)
{
	u64 *cache;
	int i;

	preempt_disable();

	cache = per_cpu(sgx_lepubkeyhash_cache, smp_processor_id());
	for (i = 0; i < 4; i++) {
		if (lepubkeyhash[i] != cache[i]) {
			wrmsrl(MSR_IA32_SGXLEPUBKEYHASH0 + i, lepubkeyhash[i]);
			cache[i] = lepubkeyhash[i];
		}
	}

	preempt_enable();
}

I'd drop sgx_einit() completely.

Finally, in sgx_encl_init() I would call sgx_update_lepubkeyhash_msrs()
directly:

/* ... */
			sgx_update_lepubkeyhash_msrs(mrsigner);

			ret = __einit(sigstruct, token, sgx_get_epc_addr(secs));
/* ... */

These staments would replace the call to sgx_einit().

Do I have the correct understanding?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 14:24       ` Borislav Petkov
@ 2020-09-23 14:52         ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 14:52 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-mm, Jethro Beekman,
	Jordan Hand, Nathaniel McCallum, Chunyang Hui, Seth Moore,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 04:24:13PM +0200, Borislav Petkov wrote:
> On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK:	Holds the offset in the Version Array
> > > > + *					(VA) page for a swapped page.
> > > >   * %SGX_ENCL_PAGE_ADDR_MASK:		Holds the virtual address of the page.
> > > >   *
> > > >   * The page address for SECS is zero and is used by the subsystem to recognize
> > > 
> > > ...
> > 
> > So what's wrong over here?
> 
> Nothing - that's just an ellipsis: https://en.wikipedia.org/wiki/Ellipsis
> 
> I do that because otherwise you'd have to scroll through pages of quoted
> mail for no good reason and that ain't friendly at all. And I notice
> people not trimming their replies and not quoting only the text they
> reply to. They should not wonder if their emails remain unread.
> 
> Thx for the rest.

OK, I'm just almost paranoic in not addressing all feedback, thanks
for the explanation :-)

Like in this version, I'll try to xref all changes so it will be at
least easier spot if something is missing.

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 16:24     ` Sean Christopherson
  2020-09-22 18:02       ` Borislav Petkov
@ 2020-09-23 15:25       ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-23 15:25 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

> 	if (IS_ERR(va_page)) <- needed a new VA page, allocation failed
> 		return PTR_ERR(va_page);
> 	else if (va_page)    <- needed a new VA page, allocation succeeded
> 		list_add(&va_page->list, &encl->va_pages);
> 	else
> 		             <- reused the current VA page

/* else the tail page of the VA page list had free slots. */

I added this comment as "the missing branch".

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-23 14:47                 ` Jarkko Sakkinen
@ 2020-09-23 15:55                   ` Borislav Petkov
  2020-09-24 12:23                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-23 15:55 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jethro Beekman, Sean Christopherson, x86, linux-sgx,
	linux-kernel, Haitao Huang, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny, Suresh Siddha,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Wed, Sep 23, 2020 at 05:47:07PM +0300, Jarkko Sakkinen wrote:
> OK, so I did not follow this particular discussion in high detail,

What do you mean you did not follow it? It is not a huge subthread in
your mbox.

> so as a sanity check I'll preview my changes.

Sorry, but you'll have to read threads properly like everyone else.

In any case, my preference would be make it the simplest possible: no
cache and try EINIT only once.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-23 13:20     ` Jarkko Sakkinen
@ 2020-09-23 16:17       ` Borislav Petkov
  2020-09-24 11:51         ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-23 16:17 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Wed, Sep 23, 2020 at 04:20:49PM +0300, Jarkko Sakkinen wrote:
> Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> called enclaves, which cannot be accessed by default when not executing
> inside the enclave. Enclaves can be entered by only using predefined memory
> addresses, which are defined the enclave is loaded.
			      ^
			      "when" or "before". I think it is before.

> However, enclaves can defined as debug enclaves during the load time. In

"However, enclaves can be defined as debug enclaves at load time."

> debug enclaves data can be read and/or written a memory word at a time by
> using by using ENCLS[EDBGRD] and ENCLS[EDBGWR] leaf instructions.

only one "by using" is enough.

> Add 'access' implementation to vm_ops with the help of these functions.

"Add an ->access virtual MM function for accessing the enclave's memory... "

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
  2020-09-15 11:28 ` [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
@ 2020-09-23 22:07   ` Borislav Petkov
  2020-09-24 12:09     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-23 22:07 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:36PM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> The basic concept and implementation is very similar to the kernel's
> exception fixup mechanism.  The key differences are that the kernel
> handler is hardcoded and the fixup entry addresses are relative to
> the overall table as opposed to individual entries.

...

This gist of this commit message should be also in
Documentation/x86/sgx.rst

And I already said the same thing during v33 review:

"That is a very good explanation and I would prefer if it would be in a
sgx-specific README or so instead of it getting lost in git..."

...

> diff --git a/arch/x86/entry/vdso/extable.h b/arch/x86/entry/vdso/extable.h
> new file mode 100644
> index 000000000000..aafdac396948
> --- /dev/null
> +++ b/arch/x86/entry/vdso/extable.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __VDSO_EXTABLE_H
> +#define __VDSO_EXTABLE_H
> +
> +/*
> + * Inject exception fixup for vDSO code.  Unlike normal exception fixup,
> + * vDSO uses a dedicated handler the addresses are relative to the overall
> + * exception table, not each individual entry.
> + */
> +#ifdef __ASSEMBLY__
> +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> +	ASM_VDSO_EXTABLE_HANDLE from to
> +
> +.macro ASM_VDSO_EXTABLE_HANDLE from:req to:req
> +	.pushsection __ex_table, "a"
> +	.long (\from) - __ex_table
> +	.long (\to) - __ex_table
> +	.popsection
> +.endm
> +#else
> +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> +	".pushsection __ex_table, \"a\"\n"      \
> +	".long (" #from ") - __ex_table\n"      \
> +	".long (" #to ") - __ex_table\n"        \
> +	".popsection\n"
> +#endif
> +
> +#endif /* __VDSO_EXTABLE_H */
> +

Also from last time:

.git/rebase-apply/patch:122: new blank line at EOF.
+


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
  2020-09-23 13:50   ` Borislav Petkov
@ 2020-09-24 11:28     ` Jarkko Sakkinen
  2020-09-24 15:54       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 11:28 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, linux-doc, Randy Dunlap,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Wed, Sep 23, 2020 at 03:50:05PM +0200, Borislav Petkov wrote:
> > +This leaf function takes an RSA-3072 signature of the enclave measurement and an
> > +optional cryptographic token. Linux does not take advantage of launch tokens.
> > +The instruction checks that the signature is signed with the key defined in
> > +**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the
> 
> That '?' wants to be '[0123]' perhaps?

What do you think of this:

"The leaf instruction checks that the measurement is correct and
signature is signed with the key hashed to the four
+**IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}** MSRs representing the SHA256 of a
public key."

I though that little more detail would make sense here (i.e. what do the
MSRs represent).

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-23 16:17       ` Borislav Petkov
@ 2020-09-24 11:51         ` Jarkko Sakkinen
  2020-09-24 15:57           ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 11:51 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > Add 'access' implementation to vm_ops with the help of these functions.
> 
> "Add an ->access virtual MM function for accessing the enclave's memory... "

Thank you. I wrote the last paragraph like this:

"Add an '->access' virtual function for accessing the enclave's memory
to vm_ops by using these functions. This allows to use ptrace() with
debug enclaves."

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
  2020-09-23 22:07   ` Borislav Petkov
@ 2020-09-24 12:09     ` Jarkko Sakkinen
  2020-09-24 16:00       ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 12:09 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 12:07:12AM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:36PM +0300, Jarkko Sakkinen wrote:
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> > 
> > The basic concept and implementation is very similar to the kernel's
> > exception fixup mechanism.  The key differences are that the kernel
> > handler is hardcoded and the fixup entry addresses are relative to
> > the overall table as opposed to individual entries.
> 
> ...
> 
> This gist of this commit message should be also in
> Documentation/x86/sgx.rst
> 
> And I already said the same thing during v33 review:
> 
> "That is a very good explanation and I would prefer if it would be in a
> sgx-specific README or so instead of it getting lost in git..."
> 
> ...

This is not technically SGX specific patch. Is SGX documentation the
correct place for this?

> > diff --git a/arch/x86/entry/vdso/extable.h b/arch/x86/entry/vdso/extable.h
> > new file mode 100644
> > index 000000000000..aafdac396948
> > --- /dev/null
> > +++ b/arch/x86/entry/vdso/extable.h
> > @@ -0,0 +1,29 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef __VDSO_EXTABLE_H
> > +#define __VDSO_EXTABLE_H
> > +
> > +/*
> > + * Inject exception fixup for vDSO code.  Unlike normal exception fixup,
> > + * vDSO uses a dedicated handler the addresses are relative to the overall
> > + * exception table, not each individual entry.
> > + */
> > +#ifdef __ASSEMBLY__
> > +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> > +	ASM_VDSO_EXTABLE_HANDLE from to
> > +
> > +.macro ASM_VDSO_EXTABLE_HANDLE from:req to:req
> > +	.pushsection __ex_table, "a"
> > +	.long (\from) - __ex_table
> > +	.long (\to) - __ex_table
> > +	.popsection
> > +.endm
> > +#else
> > +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> > +	".pushsection __ex_table, \"a\"\n"      \
> > +	".long (" #from ") - __ex_table\n"      \
> > +	".long (" #to ") - __ex_table\n"        \
> > +	".popsection\n"
> > +#endif
> > +
> > +#endif /* __VDSO_EXTABLE_H */
> > +
> 
> Also from last time:
> 
> .git/rebase-apply/patch:122: new blank line at EOF.
> +

From checkpatch I only get:

ERROR: Macros with complex values should be enclosed in parentheses
#193: FILE: arch/x86/entry/vdso/extable.h:11:
+#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
+	ASM_VDSO_EXTABLE_HANDLE from to

ERROR: need consistent spacing around '*' (ctx:WxV)
#244: FILE: arch/x86/entry/vdso/vdso2c.h:8:
+static void BITSFUNC(copy)(FILE *outfile, const unsigned char *data, size_t len)
                                 ^

ERROR: need consistent spacing around '*' (ctx:WxV)
#263: FILE: arch/x86/entry/vdso/vdso2c.h:27:
+			      FILE *outfile, ELF(Shdr) *sec, const char *name)

I did fix it now. Thanks.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT
  2020-09-23 15:55                   ` Borislav Petkov
@ 2020-09-24 12:23                     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 12:23 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Jethro Beekman, Sean Christopherson, x86, linux-sgx,
	linux-kernel, Haitao Huang, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny, Suresh Siddha,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, puiterwijk,
	rientjes, tglx, yaozhangx

On Wed, Sep 23, 2020 at 05:55:11PM +0200, Borislav Petkov wrote:
> On Wed, Sep 23, 2020 at 05:47:07PM +0300, Jarkko Sakkinen wrote:
> > OK, so I did not follow this particular discussion in high detail,
> 
> What do you mean you did not follow it? It is not a huge subthread in
> your mbox.

I focused on other subthreads but I've read it now through. It has been
waiting in the queue. Can't do everything simultaneously. I did skim
each message as they came for this one though.

> > so as a sanity check I'll preview my changes.
> 
> Sorry, but you'll have to read threads properly like everyone else.
> 
> In any case, my preference would be make it the simplest possible: no
> cache and try EINIT only once.


The main reason skimming was that I was thinking that perhaps Sean might
send a patch for this one and I would then read the thread again in
better detail and check that the patch matches the conclusions, as he
has been more active on this one.

Anyway, now that I've read it through in detail, I did just change the
init simply as:

secs_addr = sgx_get_epc_addr(encl->secs.epc_page);

preempt_disable();
ret = __einit(sigstruct, token, secs_addr);
preempt_enable();

I use a local for address to make the code  more readable instead of
calling sgx_get_epc_addr() inside __einit().

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-23 14:33             ` Jarkko Sakkinen
@ 2020-09-24 14:50               ` Dave Hansen
  2020-09-24 16:27                 ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-24 14:50 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Andy Lutomirski, Sean Christopherson, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/23/20 7:33 AM, Jarkko Sakkinen wrote:
> The consequence is that enclaves are best created with an ioctl API and the
> access control can be based only to the origin of the source file for the
> enclave data, i.e. on VMA file pointer and page permissions. For example,
> this could be done with LSM hooks that are triggered in the appropriate
> ioctl's and they could make the access control decision based on this
> information.
> 
> Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> could upgrade its permissions by using EMODPE followed by an appropriate
> mprotect() call. This would be completely hidden from the kernel.
> 
> Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> that will ensure that {mmap, mprotect}() permissions do not surpass any of
> the original page permissions. This feature allows to maintain and refine
> sane access control for enclaves.

Maybe I'm just being dense, but I still don't have a clear idea what
function this hook serves.

I understand that SGX has an orthogonal set of page permissions to the
normal x86 page tables.  It needs these so that the OS can't play nasty
tricks on the enclave, like removing read-only protections that provide
hardening.

But, I still don't get the connection to mprotect() and the x86 paging
permissions.  If the enclave's permissions are orthogonal, then why
bother with this hook?  Why does the OS view of the enclave's memory matter?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals
  2020-09-24 11:28     ` Jarkko Sakkinen
@ 2020-09-24 15:54       ` Borislav Petkov
  0 siblings, 0 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-24 15:54 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-doc, Randy Dunlap,
	Sean Christopherson, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 02:28:01PM +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 23, 2020 at 03:50:05PM +0200, Borislav Petkov wrote:
> > > +This leaf function takes an RSA-3072 signature of the enclave measurement and an
> > > +optional cryptographic token. Linux does not take advantage of launch tokens.
> > > +The instruction checks that the signature is signed with the key defined in
> > > +**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the
> > 
> > That '?' wants to be '[0123]' perhaps?
> 
> What do you think of this:
> 
> "The leaf instruction checks that the measurement is correct and
> signature is signed with the key hashed to the four
> +**IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}** MSRs representing the SHA256 of a
> public key."

ACK.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
  2020-09-24 11:51         ` Jarkko Sakkinen
@ 2020-09-24 15:57           ` Borislav Petkov
  2020-09-24 20:38             ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver' Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-24 15:57 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Thu, Sep 24, 2020 at 02:51:28PM +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > > Add 'access' implementation to vm_ops with the help of these functions.
> > 
> > "Add an ->access virtual MM function for accessing the enclave's memory... "
> 
> Thank you. I wrote the last paragraph like this:
> 
> "Add an '->access' virtual function for accessing the enclave's memory
> to vm_ops by using these functions. This allows to use ptrace() with

"to vm_ops" must come after "function".

But lemme ask what is "vm_ops"?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
  2020-09-24 12:09     ` Jarkko Sakkinen
@ 2020-09-24 16:00       ` Borislav Petkov
  2020-09-24 21:07         ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-24 16:00 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 03:09:01PM +0300, Jarkko Sakkinen wrote:
> This is not technically SGX specific patch. Is SGX documentation the
> correct place for this?

So what is it then? It is SGX implementation-specific. Why would you not
put it in the documentation?!

> From checkpatch I only get:

Please concentrate and start reading more carefully:

".git/rebase-apply/patch:122: new blank line at EOF."

Would that error come from checkpatch?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 14:50               ` Dave Hansen
@ 2020-09-24 16:27                 ` Sean Christopherson
  0 siblings, 0 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-24 16:27 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Jarkko Sakkinen, Andy Lutomirski, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 07:50:15AM -0700, Dave Hansen wrote:
> On 9/23/20 7:33 AM, Jarkko Sakkinen wrote:
> > The consequence is that enclaves are best created with an ioctl API and the
> > access control can be based only to the origin of the source file for the
> > enclave data, i.e. on VMA file pointer and page permissions. For example,
> > this could be done with LSM hooks that are triggered in the appropriate
> > ioctl's and they could make the access control decision based on this
> > information.
> > 
> > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> > could upgrade its permissions by using EMODPE followed by an appropriate
> > mprotect() call. This would be completely hidden from the kernel.
> > 
> > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> > that will ensure that {mmap, mprotect}() permissions do not surpass any of
> > the original page permissions. This feature allows to maintain and refine
> > sane access control for enclaves.
> 
> Maybe I'm just being dense, but I still don't have a clear idea what
> function this hook serves.
> 
> I understand that SGX has an orthogonal set of page permissions to the
> normal x86 page tables.  It needs these so that the OS can't play nasty
> tricks on the enclave, like removing read-only protections that provide
> hardening.
> 
> But, I still don't get the connection to mprotect() and the x86 paging
> permissions.  If the enclave's permissions are orthogonal, then why
> bother with this hook?  Why does the OS view of the enclave's memory matter?

For the purpose of this discussion, ignore the enclave permissions.  The only
reason they're mentioned is to explain the background (well, try to) of how we
ended up at an ->mprotect() hook.  There was a great deal of discussion in the
past about whether or not we could use enclave permissions to enforce OS
permissions.  The TL:DR version is that because of ENCLU[EMODPE], the answer
is "no".

What we're preventing via ->mprotect() is using SGX to bypass existing
restrictions on code execution, e.g. noexec and LSM policies.

Because code must first be loaded into an enclave before it can be executed,
all enclaves are kind of a variant on (in SELinux terminology) either EXECMOD
or EXECMEM.  I.e. it's simply not possible to execute an enclave by mapping
the source file as executable.  This effectively allows userspace to bypass a
noexec FS by loading code into an enclave without EXEC perms on the source
file, only on /dev/sgx/enclave, and denying EXEC on /dev/sgx/enclave would
prevent running _any_ enclave.

The ->mprotect() hook is used by SGX to require userspace to declare what
permissions are allowed on any given enclave page, e.g. SGX's mmap()/mprotect()
requires all underlying enclave pages to be declared as executable if the
mmap()/mprotect() is specifying VM_EXEC.  By requiring userspace to declare
their intent up front, SGX can then enforce noexec by requiring pages that are
declared as executable to have VM_MAYEXEC set in the source VMA when loading
code into the enclave.

As Jarkko pointed out, an alternative to adding ->mprotect() would be to
simply require VM_MAYEXEC on _all_ source VMAs when loading code into the
enclave.  That would work, albeit with the potentially undesirable side effect
of preventing loading any part of an enclave from e.g. a noexec, readonly FS.

But, unconditionally requiring VM_MAYEXEC doesn't address the Linux Security
Module hooks for mmap() and mprotect(), which could also be bypassed by abusing
SGX.  E.g. a process could gain arbitrary code execution by loading code from
anonymous memory into an enclave, as the LSM checks hooks at mmap()/mprotect()
will see always vm_file=/dev/sgx/enclave.  An LSM could deny a process access
to /dev/sgx/enclave, but again that is very coarse granularity.

By requiring userspace to declare permissions up front (when loading code/data
into an enclave), SGX can make explicit upcalls to LSMs hooks at load time so
that an LSM can enforce a meaningful policy, e.g. require all enclave code to
originate from an executable file system.  This series doesn't actually
implement the LSM integration, but it does ensure that _if_ we want to add LSM
support in the future, we can do so without breaking userspace.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling
  2020-09-15 11:28 ` [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
@ 2020-09-24 16:31   ` Borislav Petkov
  2020-09-24 23:11     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-24 16:31 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:38PM +0300, Jarkko Sakkinen wrote:
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 9e5ec861aba0..ebe290a68c36 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -30,6 +30,7 @@
>  #include <asm/cpu_entry_area.h>		/* exception stack		*/
>  #include <asm/pgtable_areas.h>		/* VMALLOC_START, ...		*/
>  #include <asm/kvm_para.h>		/* kvm_handle_async_pf		*/
> +#include <asm/vdso.h>			/* fixup_vdso_exception()	*/
>  
>  #define CREATE_TRACE_POINTS
>  #include <asm/trace/exceptions.h>
> @@ -775,6 +776,10 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
>  
>  		sanitize_error_code(address, &error_code);
>  
> +		if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code,
> +		    address))

No need to break that line.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-15 11:28 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
@ 2020-09-24 18:04   ` Borislav Petkov
  2020-09-25  1:00     ` Jarkko Sakkinen
       [not found]     ` <20200925003808.GB20333@linux.intel.com>
  2020-09-25 18:23   ` Andrew Cooper
  1 sibling, 2 replies; 180+ messages in thread
From: Borislav Petkov @ 2020-09-24 18:04 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Tue, Sep 15, 2020 at 02:28:39PM +0300, Jarkko Sakkinen wrote:
> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> new file mode 100644
> index 000000000000..adbd59d41517
> --- /dev/null
> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S

Why not simply

arch/x86/entry/vdso/sgx.S

?

> @@ -0,0 +1,157 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include <linux/linkage.h>
> +#include <asm/export.h>
> +#include <asm/errno.h>
> +#include <asm/enclu.h>
> +
> +#include "extable.h"
> +
> +/* Offset of 'struct sgx_enclave_run' relative to %rbp. */
> +#define SGX_ENCLAVE_RUN_PTR	2*8
> +
> +/* Offsets into 'struct sgx_enclave_run'. */
> +#define SGX_ENCLAVE_RUN_TSC		0*8
> +#define SGX_ENCLAVE_RUN_FLAGS		1*8
> +#define SGX_ENCLAVE_RUN_EXIT_REASON	1*8 + 4
> +#define SGX_ENCLAVE_RUN_USER_HANDLER	2*8
> +/* #define SGX_ENCLAVE_RUN_USER_DATA	3*8 */

What's with that guy? Left here as documentation showing what's at 3*8
offset?

> +#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
> +
> +#define SGX_SYNCHRONOUS_EXIT		0
> +#define SGX_EXCEPTION_EXIT		1

Those are in ...uapi/asm/sgx.h too. Unify?

> +
> +/* Offsets into sgx_enter_enclave.exception. */
> +#define SGX_EX_LEAF			0*8
> +#define SGX_EX_TRAPNR			0*8+4
> +#define SGX_EX_ERROR_CODE		0*8+6
> +#define SGX_EX_ADDRESS			1*8
> +
> +.code64
> +.section .text, "ax"
> +
> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> +	/* Prolog */
> +	.cfi_startproc

Are the CFI annotations for userspace?

> +	push	%rbp
> +	.cfi_adjust_cfa_offset	8
> +	.cfi_rel_offset		%rbp, 0
> +	mov	%rsp, %rbp
> +	.cfi_def_cfa_register	%rbp
> +	push	%rbx
> +	.cfi_rel_offset		%rbx, -8
> +
> +	mov	%ecx, %eax
> +.Lenter_enclave:
> +	/* EENTER <= leaf <= ERESUME */
> +	cmp	$EENTER, %eax
> +	jb	.Linvalid_input
> +	cmp	$ERESUME, %eax
> +	ja	.Linvalid_input
> +
> +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rcx
> +
> +	/* No flags are currently defined/supported. */
> +	cmpl	$0, SGX_ENCLAVE_RUN_FLAGS(%rcx)
> +	jne	.Linvalid_input
> +
> +	/* Load TCS and AEP */

		TSC

I can see why you would write "TCS" though - there's a thread control
structure thing too in that patch.

> +	mov	SGX_ENCLAVE_RUN_TSC(%rcx), %rbx
> +	lea	.Lasync_exit_pointer(%rip), %rcx
> +
> +	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
> +.Lasync_exit_pointer:
> +.Lenclu_eenter_eresume:
> +	enclu
> +
> +	/* EEXIT jumps here unless the enclave is doing something fancy. */
> +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
> +
> +	/* Set exit_reason. */
> +	movl	$SGX_SYNCHRONOUS_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
> +
> +	/* Invoke userspace's exit handler if one was provided. */
> +.Lhandle_exit:
> +	cmpq	$0, SGX_ENCLAVE_RUN_USER_HANDLER(%rbx)
> +	jne	.Linvoke_userspace_handler
> +
> +	/* Success, in the sense that ENCLU was attempted. */
> +	xor	%eax, %eax
> +
> +.Lout:
> +	pop	%rbx
> +	leave
> +	.cfi_def_cfa		%rsp, 8
> +	ret
> +
> +	/* The out-of-line code runs with the pre-leave stack frame. */
> +	.cfi_def_cfa		%rbp, 16
> +
> +.Linvalid_input:
> +	mov	$(-EINVAL), %eax
> +	jmp	.Lout
> +
> +.Lhandle_exception:
> +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
> +
> +	/* Set the exit_reason and exception info. */
> +	movl	$SGX_EXCEPTION_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
> +
> +	mov	%eax, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_LEAF)(%rbx)
> +	mov	%di,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_TRAPNR)(%rbx)
> +	mov	%si,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ERROR_CODE)(%rbx)
> +	mov	%rdx, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ADDRESS)(%rbx)
> +	jmp	.Lhandle_exit
> +
> +.Linvoke_userspace_handler:
> +	/* Pass the untrusted RSP (at exit) to the callback via %rcx. */
> +	mov	%rsp, %rcx
> +
> +	/* Save @e, %rbx is about to be clobbered. */

I've been wondering what that "@e" thing is and I believe I've found it at the
end: "... @e, the optional sgx_enclave_exception struct"

Yes?

Please rewrite what that "e" is here - I think you wanna say "struct
sgx_enclave_run.exception" instead to clarify.

...

> diff --git a/arch/x86/include/asm/enclu.h b/arch/x86/include/asm/enclu.h
> new file mode 100644
> index 000000000000..06157b3e9ede
> --- /dev/null
> +++ b/arch/x86/include/asm/enclu.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_X86_ENCLU_H
> +#define _ASM_X86_ENCLU_H
> +
> +#define EENTER	0x02
> +#define ERESUME	0x03
> +
> +#endif /* _ASM_X86_ENCLU_H */
> diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
> index d0916fb9629e..1564d7f88597 100644
> --- a/arch/x86/include/uapi/asm/sgx.h
> +++ b/arch/x86/include/uapi/asm/sgx.h

Are all those defines being added to the uapi header, also actually
needed by userspace?

> @@ -72,4 +72,132 @@ struct sgx_enclave_provision {
>  	__u64 attribute_fd;
>  };
>  
> +#define SGX_SYNCHRONOUS_EXIT	0
> +#define SGX_EXCEPTION_EXIT	1
> +
> +struct sgx_enclave_run;
> +
> +/**
> + * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
> + *					__vdso_sgx_enter_enclave()
> + *
> + * @rdi:	RDI at the time of enclave exit
> + * @rsi:	RSI at the time of enclave exit
> + * @rdx:	RDX at the time of enclave exit
> + * @ursp:	RSP at the time of enclave exit (untrusted stack)
> + * @r8:		R8 at the time of enclave exit
> + * @r9:		R9 at the time of enclave exit

I'm sure you can avoid that "at the time of enclave exit" repetition.

...

> +/**
> + * typedef vdso_sgx_enter_enclave_t - Prototype for __vdso_sgx_enter_enclave(),
> + *				      a vDSO function to enter an SGX enclave.
> + *
> + * @rdi:	Pass-through value for RDI
> + * @rsi:	Pass-through value for RSI
> + * @rdx:	Pass-through value for RDX
> + * @leaf:	ENCLU leaf, must be EENTER or ERESUME
> + * @r8:		Pass-through value for R8
> + * @r9:		Pass-through value for R9
> + * @r:		struct sgx_enclave_run, must be non-NULL
> + *
> + * NOTE: __vdso_sgx_enter_enclave() does not ensure full compliance with the
> + * x86-64 ABI, e.g. doesn't handle XSAVE state.  Except for non-volatile
> + * general purpose registers, EFLAGS.DF, and RSP alignment, preserving/setting
> + * state in accordance with the x86-64 ABI is the responsibility of the enclave
> + * and its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C
> + * code without careful consideration by both the enclave and its runtime.
> + *
> + * All general purpose registers except RAX, RBX and RCX are passed as-is to
> + * the enclave.  RAX, RBX and RCX are consumed by EENTER and ERESUME and are
> + * loaded with @leaf, asynchronous exit pointer, and @tcs respectively.

That tcs is probably struct sgx_enclave_run.tcs?

> + * RBP and the stack are used to anchor __vdso_sgx_enter_enclave() to the
> + * pre-enclave state, e.g. to retrieve @e and @handler after an enclave exit.

Expand @e and do you mean "@user_handler" with "@handler"?

> + * All other registers are available for use by the enclave and its runtime,
> + * e.g. an enclave can push additional data onto the stack (and modify RSP) to
> + * pass information to the optional exit handler (see below).
> + *
> + * Most exceptions reported on ENCLU, including those that occur within the
> + * enclave, are fixed up and reported synchronously instead of being delivered
> + * via a standard signal. Debug Exceptions (#DB) and Breakpoints (#BP) are
> + * never fixed up and are always delivered via standard signals. On synchrously
> + * reported exceptions, -EFAULT is returned and details about the exception are
> + * recorded in @e, the optional sgx_enclave_exception struct.
> + *
> + * If an exit handler is provided, the handler will be invoked on synchronous
> + * exits from the enclave and for all synchronously reported exceptions. In
> + * latter case, @e is filled prior to invoking the handler.
> + *
> + * The exit handler's return value is interpreted as follows:
> + *  >0:		continue, restart __vdso_sgx_enter_enclave() with @ret as @leaf
> + *   0:		success, return @ret to the caller
> + *  <0:		error, return @ret to the caller
> + *
> + * The exit handler may transfer control, e.g. via longjmp() or C++ exception,
> + * without returning to __vdso_sgx_enter_enclave().
> + *
> + * Return:
> + *  0 on success (ENCLU reached),
> + *  -EINVAL if ENCLU leaf is not allowed,
> + *  -errno for all other negative values returned by the userspace exit handler
> + */
> +typedef int (*vdso_sgx_enter_enclave_t)(unsigned long rdi, unsigned long rsi,
> +					unsigned long rdx, unsigned int leaf,
> +					unsigned long r8,  unsigned long r9,
> +					struct sgx_enclave_run *r);
> +
>  #endif /* _UAPI_ASM_X86_SGX_H */
> -- 
> 2.25.1
> 

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-23 13:50                     ` Jarkko Sakkinen
@ 2020-09-24 19:11                       ` Haitao Huang
  2020-09-24 19:28                         ` Sean Christopherson
  2020-09-24 21:55                         ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Haitao Huang @ 2020-09-24 19:11 UTC (permalink / raw)
  To: Sean Christopherson, Jarkko Sakkinen
  Cc: Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen  
<jarkko.sakkinen@linux.intel.com> wrote:

> On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote:
>> On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote:
>> > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
>> > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
>> > > > Userspace can add the page without EXEC permissions in the EPCM,  
>> and thus
>> > > > avoid the noexec/VM_MAYEXEC check.  The enclave can then do  
>> EMODPE to gain
>> > > > EXEC permissions in the EPMC.  Without the ->mprotect() hook, we  
>> wouldn't
>> > > > be able to detect/prevent such shenanigans.
>> > >
>> > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
>> > >
>> > > I'm only wondering why not block noexec completely with any  
>> permissions,
>> > > i.e. why not just have unconditional VM_MAYEXEC check?
>> >
>> > I.e. why not this:
>> >
>> > static int __sgx_encl_add_page(struct sgx_encl *encl,
>> > 			       struct sgx_encl_page *encl_page,
>> > 			       struct sgx_epc_page *epc_page,
>> > 			       struct sgx_secinfo *secinfo, unsigned long src)
>> > {
>> > 	struct sgx_pageinfo pginfo;
>> > 	struct vm_area_struct *vma;
>> > 	struct page *src_page;
>> > 	int ret;
>> >
>> > 	vma = find_vma(current->mm, src);
>> > 	if (!vma)
>> > 		return -EFAULT;
>> >
>> > 	if (!(vma->vm_flags & VM_MAYEXEC))
>> > 		return -EACCES;
>> >
>> > I'm not seeing the reason for "partial support" for noexec partitions.
>> >
>> > If there is a good reason, fine, let's just then document it.
>>
>> There are scenarios I can contrive, e.g. loading an enclave from a  
>> noexec
>> filesystem without having to copy the entire enclave to anon memory, or
>> loading a data payload from a noexec FS.
>>
>> They're definitely contrived scenarios, but given that we also want the
>> ->mprotect() hook/behavior for potential LSM interaction, supporting  
>> said
>> contrived scenarios costs is "free".
>
> For me this has caused months of confusion and misunderstanding of this
> feature. I only recently realized that "oh, right, we invented this".
>
> They are contrived scenarios enough that they should be considered when
> the workloads hit.
>
> Either we fully support noexec or not at all. Any "partial" thing is a
> two edged sword: it can bring some robustness with the price of
> complexity and possible unknown uknown scenarios where they might become
> API issue.
>
> I rather think later on how to extend API in some way to enable such
> contrivid scenarios rather than worrying about how this could be abused.
>
> The whole SGX is complex beast already so lets not add any extra when
> there is no a hard requirement to do so.
>
> I'll categorically deny noexec in the next patch set version.
>
> /Jarkko

There are use cases supported currently in which enclave binary is  
received via IPC/RPC and held in buffers before EADD. Denying noexec  
altogether would break those, right?
 

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 19:11                       ` Haitao Huang
@ 2020-09-24 19:28                         ` Sean Christopherson
  2020-09-24 19:39                           ` Dave Hansen
  2020-09-24 21:58                           ` Jarkko Sakkinen
  2020-09-24 21:55                         ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-24 19:28 UTC (permalink / raw)
  To: Haitao Huang
  Cc: Jarkko Sakkinen, Andy Lutomirski, X86 ML, linux-sgx, LKML,
	Linux-MM, Andrew Morton, Matthew Wilcox, Jethro Beekman,
	Darren Kenny, Andy Shevchenko, asapek, Borislav Petkov, Xing,
	Cedric, chenalexchen, Conrad Parker, cyhanish, Dave Hansen,
	Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >I'll categorically deny noexec in the next patch set version.
> >
> >/Jarkko
> 
> There are use cases supported currently in which enclave binary is received
> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would
> break those, right?

No.  noexec only applies to file-backed VMAs, what you're describing is loading
an enclave from an anon VMA, which will still have VM_MAYEXEC.

I believe you're thinking of SELinux's EXECMEM, which is required to execute
from anonymous memory, and which we talked about (more than once) applying to
SGX enclaves.

That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack
that doesn't really buy us much, if anything.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 19:28                         ` Sean Christopherson
@ 2020-09-24 19:39                           ` Dave Hansen
  2020-09-24 20:01                             ` Sean Christopherson
  2020-09-24 21:58                           ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-24 19:39 UTC (permalink / raw)
  To: Sean Christopherson, Haitao Huang
  Cc: Jarkko Sakkinen, Andy Lutomirski, X86 ML, linux-sgx, LKML,
	Linux-MM, Andrew Morton, Matthew Wilcox, Jethro Beekman,
	Darren Kenny, Andy Shevchenko, asapek, Borislav Petkov, Xing,
	Cedric, chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/24/20 12:28 PM, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
>> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
>> <jarkko.sakkinen@linux.intel.com> wrote:
>>> I'll categorically deny noexec in the next patch set version.
>>>
>>> /Jarkko
>> There are use cases supported currently in which enclave binary is received
>> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would
>> break those, right?
> No.  noexec only applies to file-backed VMAs, what you're describing is loading
> an enclave from an anon VMA, which will still have VM_MAYEXEC.

Maybe I'm just stupid, but I still don't get the scenario that's being
thwarted or why it is valuable.  The SDM is worthless on what EMODPE
does or what its restrictions are.

In pseudo-C, it's something logically like this for the "nice" case:

	ptr = mmap("/some/executable", PROT_EXEC);
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
	mmap(sgx_fd);
	EENTER;

And we're trying to thwart:

	ptr = mmap("/mnt/noexec/file", PROT_READ);
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
	mmap(sgx_fd);
	EENTER;

because that loads data into the enclave which is executable but which
was not executable normally.  But, we're allowing this from anonymous
memory, so this would seem to work:

	ptr = mmap("/mnt/noexec/file", PROT_READ);
	buffer = malloc(PAGE_SIZE);
	memcpy(buffer, ptr, PAGE_SIZE);
	// need mprotect(buf, PROT_EXEC)???
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
	mmap(sgx_fd);
	EENTER;

and give the same result.  What am I missing?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 19:39                           ` Dave Hansen
@ 2020-09-24 20:01                             ` Sean Christopherson
  2020-09-24 20:10                               ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-24 20:01 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 12:39:24PM -0700, Dave Hansen wrote:
> On 9/24/20 12:28 PM, Sean Christopherson wrote:
> > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> >> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> >> <jarkko.sakkinen@linux.intel.com> wrote:
> >>> I'll categorically deny noexec in the next patch set version.
> >>>
> >>> /Jarkko
> >> There are use cases supported currently in which enclave binary is received
> >> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would
> >> break those, right?
> > No.  noexec only applies to file-backed VMAs, what you're describing is loading
> > an enclave from an anon VMA, which will still have VM_MAYEXEC.
> 
> Maybe I'm just stupid, but I still don't get the scenario that's being
> thwarted or why it is valuable.  The SDM is worthless on what EMODPE
> does or what its restrictions are.
> 
> In pseudo-C, it's something logically like this for the "nice" case:
> 
> 	ptr = mmap("/some/executable", PROT_EXEC);
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> And we're trying to thwart:
> 
> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> because that loads data into the enclave which is executable but which
> was not executable normally.  But, we're allowing this from anonymous
> memory, so this would seem to work:
> 
> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> 	buffer = malloc(PAGE_SIZE);
> 	memcpy(buffer, ptr, PAGE_SIZE);
> 	// need mprotect(buf, PROT_EXEC)???
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> and give the same result.  What am I missing?

The last example, where the enclave is copied to a buffer, is out of scope
for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
SGX specific equivalent).

The ->mprotect() hook gives us direct line of sight to such LSM upcalls,
e.g. I have fully working code that implements the LSM integration.  LSM
support isn't in this series because the only thing everyone could agree on
in terms of an LSM implementation is that it wasn't needed for initial
upstreaming :-)

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 20:01                             ` Sean Christopherson
@ 2020-09-24 20:10                               ` Dave Hansen
  2020-09-24 20:25                                 ` Sean Christopherson
  2020-09-24 22:07                                 ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-24 20:10 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/24/20 1:01 PM, Sean Christopherson wrote:
>> In pseudo-C, it's something logically like this for the "nice" case:
>>
>> 	ptr = mmap("/some/executable", PROT_EXEC);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> And we're trying to thwart:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> because that loads data into the enclave which is executable but which
>> was not executable normally.  But, we're allowing this from anonymous
>> memory, so this would seem to work:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	buffer = malloc(PAGE_SIZE);
>> 	memcpy(buffer, ptr, PAGE_SIZE);
>> 	// need mprotect(buf, PROT_EXEC)???
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> and give the same result.  What am I missing?
> The last example, where the enclave is copied to a buffer, is out of scope
> for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> SGX specific equivalent).

Why don't we just declare enclave memory as "out of scope for noexec" in
the same way that anonymous memory is, and just discard this patch?
That doesn't seem too much of a stretch.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 20:10                               ` Dave Hansen
@ 2020-09-24 20:25                                 ` Sean Christopherson
  2020-09-24 20:54                                   ` Dave Hansen
  2020-09-24 22:07                                 ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-24 20:25 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote:
> On 9/24/20 1:01 PM, Sean Christopherson wrote:
> >> In pseudo-C, it's something logically like this for the "nice" case:
> >>
> >> 	ptr = mmap("/some/executable", PROT_EXEC);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> And we're trying to thwart:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> because that loads data into the enclave which is executable but which
> >> was not executable normally.  But, we're allowing this from anonymous
> >> memory, so this would seem to work:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	buffer = malloc(PAGE_SIZE);
> >> 	memcpy(buffer, ptr, PAGE_SIZE);
> >> 	// need mprotect(buf, PROT_EXEC)???
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> and give the same result.  What am I missing?
> > The last example, where the enclave is copied to a buffer, is out of scope
> > for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> > SGX specific equivalent).
> 
> Why don't we just declare enclave memory as "out of scope for noexec" in
> the same way that anonymous memory is, and just discard this patch?
> That doesn't seem too much of a stretch.

Because we lose line of sight to LSM support.  Without enforcing "declare perms
at load time" in the initial series, we would create an ABI where userspace
could load an enclave page with only READ permissions and then map the enclave
with whatever permissions it wants, without any convenient way for SGX to call
into the LSM.

Retroactively enforcing permissions at load time would break the ABI, or at
least yield different behavior based on the mere existence of LSMs, e.g. if
LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks,
even if there is no LSM policy denying that behavior.

Enforcing LSM policies using the existing mmap()/mprotect() hooks doesn't work
well because the only information available is a fd pointing at
/dev/sgx/enclave, which is largely useless because /dev/sgx/enclave must be
map SHARED w/ RWX to run an enclave.  We explored things like grabbing a
reference to the source file for later verification, but that means pinning
files for the entire lifetime of an enclave.

Enforcing noexec was an easy/obvious addition since we need 99% of the code for
potential LSM support anyways.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-24 15:57           ` Borislav Petkov
@ 2020-09-24 20:38             ` Jarkko Sakkinen
  2020-09-24 20:40               ` Jarkko Sakkinen
  2020-09-25  7:51               ` Borislav Petkov
  0 siblings, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 20:38 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Thu, Sep 24, 2020 at 05:57:51PM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 02:51:28PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > > > Add 'access' implementation to vm_ops with the help of these functions.
> > > 
> > > "Add an ->access virtual MM function for accessing the enclave's memory... "
> > 
> > Thank you. I wrote the last paragraph like this:
> > 
> > "Add an '->access' virtual function for accessing the enclave's memory
> > to vm_ops by using these functions. This allows to use ptrace() with
> 
> "to vm_ops" must come after "function".
> 
> But lemme ask what is "vm_ops"?

I assume this is a rethorical question and I notice what I suggested
looks as bad as my earlier commit message :-)

So, I gave it some thought that and decided to "open code" the paragraph
as

"Add sgx_vma_access() function that implements 'access' virtual function
of struct vm_operations_struct. Use formentioned leaf instructions to
achieve read and write primitives for the enclave memory."

I think this starts to have the right balance and is understandable.

Still open for futher suggestion of course.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-24 20:38             ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver' Jarkko Sakkinen
@ 2020-09-24 20:40               ` Jarkko Sakkinen
  2020-09-25  7:53                 ` Borislav Petkov
  2020-09-25  7:51               ` Borislav Petkov
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 20:40 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Thu, Sep 24, 2020 at 11:39:07PM +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 05:57:51PM +0200, Borislav Petkov wrote:
> > On Thu, Sep 24, 2020 at 02:51:28PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > > > > Add 'access' implementation to vm_ops with the help of these functions.
> > > > 
> > > > "Add an ->access virtual MM function for accessing the enclave's memory... "
> > > 
> > > Thank you. I wrote the last paragraph like this:
> > > 
> > > "Add an '->access' virtual function for accessing the enclave's memory
> > > to vm_ops by using these functions. This allows to use ptrace() with
> > 
> > "to vm_ops" must come after "function".
> > 
> > But lemme ask what is "vm_ops"?
> 
> I assume this is a rethorical question and I notice what I suggested
> looks as bad as my earlier commit message :-)
> 
> So, I gave it some thought that and decided to "open code" the paragraph
> as
> 
> "Add sgx_vma_access() function that implements 'access' virtual function
> of struct vm_operations_struct. Use formentioned leaf instructions to
> achieve read and write primitives for the enclave memory."
> 
> I think this starts to have the right balance and is understandable.
> 
> Still open for futher suggestion of course.

I'm not sure if I said it already but I also added cc to linux-mm (same
CC's in the patch as with mprotect callback commit). This should also
have mm ack I think.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 20:25                                 ` Sean Christopherson
@ 2020-09-24 20:54                                   ` Dave Hansen
  2020-09-24 23:05                                     ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-24 20:54 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/24/20 1:25 PM, Sean Christopherson wrote:
...
>> Why don't we just declare enclave memory as "out of scope for noexec" in
>> the same way that anonymous memory is, and just discard this patch?
>> That doesn't seem too much of a stretch.
> 
> Because we lose line of sight to LSM support.  Without enforcing "declare perms
> at load time" in the initial series, we would create an ABI where userspace
> could load an enclave page with only READ permissions and then map the enclave
> with whatever permissions it wants, without any convenient way for SGX to call
> into the LSM.

This argument holds no water for me.  LSMs are all about taking what
would otherwise be perfectly acceptable behavior and breaking them in
the name of security.  They fundamentally break applications that used
to work just fine and also did totally sane things.

> Retroactively enforcing permissions at load time would break the ABI, or at
> least yield different behavior based on the mere existence of LSMs, e.g. if
> LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks,
> even if there is no LSM policy denying that behavior.

I'm a security dummy.  All I know is that when I see something like this:

	if (security_vm_enough_memory_mm(mm, grow))
		...

I know to ignore it because I like my systems to boot and I'm not using
those hooks.  :)

How could the mere presence of an LSM change the behavior of one of
these hooks?  Don't they have to actually hook into the specific place
and actively go trying to change the behavior at that site?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions
  2020-09-24 16:00       ` Borislav Petkov
@ 2020-09-24 21:07         ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 21:07 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 06:00:57PM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 03:09:01PM +0300, Jarkko Sakkinen wrote:
> > This is not technically SGX specific patch. Is SGX documentation the
> > correct place for this?
> 
> So what is it then? It is SGX implementation-specific. Why would you not
> put it in the documentation?!
> 
> > From checkpatch I only get:
> 
> Please concentrate and start reading more carefully:
> 
> ".git/rebase-apply/patch:122: new blank line at EOF."
> 
> Would that error come from checkpatch?

Nope. And I did fully read what you wrote. I just mentioned that more in
the tone that I should (and will) do also git am test from now on, at
least for mainline tree (when applicable) and x86 tip.

Right now the static tests that I do are checkpatch and sparse. Any
other suggestions are welcome.

I would also also coccicheck but have had some version issues with it in
Ubuntu, which I use as my host OS. Cannot recall what was the exact
issue, has been a while since I last tried it.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 19:11                       ` Haitao Huang
  2020-09-24 19:28                         ` Sean Christopherson
@ 2020-09-24 21:55                         ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 21:55 UTC (permalink / raw)
  To: Haitao Huang
  Cc: Sean Christopherson, Andy Lutomirski, X86 ML, linux-sgx, LKML,
	Linux-MM, Andrew Morton, Matthew Wilcox, Jethro Beekman,
	Darren Kenny, Andy Shevchenko, asapek, Borislav Petkov, Xing,
	Cedric, chenalexchen, Conrad Parker, cyhanish, Dave Hansen,
	Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > For me this has caused months of confusion and misunderstanding of this
> > feature. I only recently realized that "oh, right, we invented this".
> > 
> > They are contrived scenarios enough that they should be considered when
> > the workloads hit.
> > 
> > Either we fully support noexec or not at all. Any "partial" thing is a
> > two edged sword: it can bring some robustness with the price of
> > complexity and possible unknown uknown scenarios where they might become
> > API issue.
> > 
> > I rather think later on how to extend API in some way to enable such
> > contrivid scenarios rather than worrying about how this could be abused.
> > 
> > The whole SGX is complex beast already so lets not add any extra when
> > there is no a hard requirement to do so.
> > 
> > I'll categorically deny noexec in the next patch set version.
> > 
> > /Jarkko
> 
> There are use cases supported currently in which enclave binary is received
> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would
> break those, right?

I do not see why data cannot be provided at run-time. AFAIK, it is not
different from executables how this works when it comes to noexec.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 19:28                         ` Sean Christopherson
  2020-09-24 19:39                           ` Dave Hansen
@ 2020-09-24 21:58                           ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 21:58 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 12:28:54PM -0700, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> > <jarkko.sakkinen@linux.intel.com> wrote:
> > >I'll categorically deny noexec in the next patch set version.
> > >
> > >/Jarkko
> > 
> > There are use cases supported currently in which enclave binary is received
> > via IPC/RPC and held in buffers before EADD. Denying noexec altogether would
> > break those, right?
> 
> No.  noexec only applies to file-backed VMAs, what you're describing is loading
> an enclave from an anon VMA, which will still have VM_MAYEXEC.
> 
> I believe you're thinking of SELinux's EXECMEM, which is required to execute
> from anonymous memory, and which we talked about (more than once) applying to
> SGX enclaves.
> 
> That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack
> that doesn't really buy us much, if anything.

I think it makes sense as long as it is not half-way there solution.

Either require it for the full binary or not at all. I'm fine with
either.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 20:10                               ` Dave Hansen
  2020-09-24 20:25                                 ` Sean Christopherson
@ 2020-09-24 22:07                                 ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 22:07 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote:
> On 9/24/20 1:01 PM, Sean Christopherson wrote:
> >> In pseudo-C, it's something logically like this for the "nice" case:
> >>
> >> 	ptr = mmap("/some/executable", PROT_EXEC);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> And we're trying to thwart:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> because that loads data into the enclave which is executable but which
> >> was not executable normally.  But, we're allowing this from anonymous
> >> memory, so this would seem to work:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	buffer = malloc(PAGE_SIZE);
> >> 	memcpy(buffer, ptr, PAGE_SIZE);
> >> 	// need mprotect(buf, PROT_EXEC)???
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> and give the same result.  What am I missing?
> > The last example, where the enclave is copied to a buffer, is out of scope
> > for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> > SGX specific equivalent).
> 
> Why don't we just declare enclave memory as "out of scope for noexec" in
> the same way that anonymous memory is, and just discard this patch?
> That doesn't seem too much of a stretch.

I did that already for v39. It unconditionally discards noexec
partitions.

I see EMODPE as the key driver for this patch, not noexec partitions.

I.e. post you've done SGX_IOC_ENCLAVE_INIT you are capped when it
comes to permissions.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 20:54                                   ` Dave Hansen
@ 2020-09-24 23:05                                     ` Sean Christopherson
  2020-09-24 23:09                                       ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-24 23:05 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 01:54:09PM -0700, Dave Hansen wrote:
> On 9/24/20 1:25 PM, Sean Christopherson wrote:
> ...
> >> Why don't we just declare enclave memory as "out of scope for noexec" in
> >> the same way that anonymous memory is, and just discard this patch?
> >> That doesn't seem too much of a stretch.
> > 
> > Because we lose line of sight to LSM support.  Without enforcing "declare perms
> > at load time" in the initial series, we would create an ABI where userspace
> > could load an enclave page with only READ permissions and then map the enclave
> > with whatever permissions it wants, without any convenient way for SGX to call
> > into the LSM.
> 
> This argument holds no water for me.  LSMs are all about taking what
> would otherwise be perfectly acceptable behavior and breaking them in
> the name of security.  They fundamentally break applications that used
> to work just fine and also did totally sane things.

It's not about LSMs breaking things, they can obviously do that without any
help.  The concern is that, unless we lay the groundwork now, adding support
for LSMs in the future will break existing applications or create an unholy
mess of an ABI.

If we want to support LSM policy for enclave page permissions, checking LSM
policies at load time and hooking mprotect() to enforce the policy at run
time is by far the cleanest solution of the many ideas we discussed.

The problem is that enforcing permissions via mprotect() needs to be done
unconditionally, otherwise we end up with weird behavior where the existence
of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
policy whatsover.

And on the flip side, enforcing permissions unconditionally will break
backwards compatibility.

I'm a-ok if we want to kill off the ->mprotect() hook, so long as we
acknowledge that in doing so we are likely throwing in the towel on supporting
LSM policies for enclave page permissions.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 23:05                                     ` Sean Christopherson
@ 2020-09-24 23:09                                       ` Dave Hansen
  2020-09-25  0:00                                         ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-24 23:09 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/24/20 4:05 PM, Sean Christopherson wrote:
> The problem is that enforcing permissions via mprotect() needs to be done
> unconditionally, otherwise we end up with weird behavior where the existence
> of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
> policy whatsover.

Could we make this a bit less abstract, please?

Could someone point to code or another examples that demonstrates how
the mere existence of an LSM will change what is/isn't allowed?

I can't seem to wrap my head around it as-is.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling
  2020-09-24 16:31   ` Borislav Petkov
@ 2020-09-24 23:11     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-24 23:11 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, akpm, andriy.shevchenko, asapek,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 06:31:28PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:38PM +0300, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index 9e5ec861aba0..ebe290a68c36 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -30,6 +30,7 @@
> >  #include <asm/cpu_entry_area.h>		/* exception stack		*/
> >  #include <asm/pgtable_areas.h>		/* VMALLOC_START, ...		*/
> >  #include <asm/kvm_para.h>		/* kvm_handle_async_pf		*/
> > +#include <asm/vdso.h>			/* fixup_vdso_exception()	*/
> >  
> >  #define CREATE_TRACE_POINTS
> >  #include <asm/trace/exceptions.h>
> > @@ -775,6 +776,10 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
> >  
> >  		sanitize_error_code(address, &error_code);
> >  
> > +		if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code,
> > +		    address))
> 
> No need to break that line.

Thanks, fixed.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-24 23:09                                       ` Dave Hansen
@ 2020-09-25  0:00                                         ` Sean Christopherson
  2020-09-25 17:18                                           ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-25  0:00 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Thu, Sep 24, 2020 at 04:09:25PM -0700, Dave Hansen wrote:
> On 9/24/20 4:05 PM, Sean Christopherson wrote:
> > The problem is that enforcing permissions via mprotect() needs to be done
> > unconditionally, otherwise we end up with weird behavior where the existence
> > of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
> > policy whatsover.
> 
> Could we make this a bit less abstract, please?
> 
> Could someone point to code or another examples that demonstrates how
> the mere existence of an LSM will change what is/isn't allowed?
> 
> I can't seem to wrap my head around it as-is.

Without pre-declared permissions, loading and running an enclave would be:

	ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);

	EENTER;

With the existing security_file_mprotect(), an LSM will see:

        vma->vm_file ~= /dev/sgx/enclave
        prot = PROT_READ | PROT_EXEC

From a policy perspective, the LSM can't do much because every enclave is
backed by /dev/sgx/enclave, and all enclaves need READ and EXEC perms, i.e.
a policy can only deny all enclaves or allow enclaves.

The solution we came up with is to require userspace to declare the intended
permissions at build time so that an LSM hook can be invoked when the source
VMA is availble, e.g. in this example, the LSM would see that the process is
loading executable code into an enclave from an anonymous VMA:

        ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
        {
                ret = security_enclave_load(ptr, prot);
                if (ret)
                        return ret;

                enclave_page->declared_prot = prot;
        }
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

and then enforce the declared perms via ->mprotect()

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);
        |
        -> sgx_mprotect(...)
           {
                   if (~enclave_page->declared_prot & prot)
                        return -EACCES;
           }

	EENTER;

So the above would be allowed, but this would fail (irrespective of LSM behavior):

        ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ, ptr, size);
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);


My concern is that if we merge this

        ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);

without ->mprotect(), we can't actually enforce the declared protections.  And
if we drop the field altogether:

        ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);

then we can't implement security_enclave_load().

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-24 18:04   ` Borislav Petkov
@ 2020-09-25  1:00     ` Jarkko Sakkinen
  2020-09-25  8:28       ` Borislav Petkov
  2020-09-25  8:39       ` Jethro Beekman
       [not found]     ` <20200925003808.GB20333@linux.intel.com>
  1 sibling, 2 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25  1:00 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Thu, Sep 24, 2020 at 08:04:07PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:39PM +0300, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > new file mode 100644
> > index 000000000000..adbd59d41517
> > --- /dev/null
> > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> 
> Why not simply
> 
> arch/x86/entry/vdso/sgx.S
> 
> ?

I renamed it as vsgx.S (for the sake of convention).

> > @@ -0,0 +1,157 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#include <linux/linkage.h>
> > +#include <asm/export.h>
> > +#include <asm/errno.h>
> > +#include <asm/enclu.h>
> > +
> > +#include "extable.h"
> > +
> > +/* Offset of 'struct sgx_enclave_run' relative to %rbp. */
> > +#define SGX_ENCLAVE_RUN_PTR	2*8
> > +
> > +/* Offsets into 'struct sgx_enclave_run'. */
> > +#define SGX_ENCLAVE_RUN_TSC		0*8
> > +#define SGX_ENCLAVE_RUN_FLAGS		1*8
> > +#define SGX_ENCLAVE_RUN_EXIT_REASON	1*8 + 4
> > +#define SGX_ENCLAVE_RUN_USER_HANDLER	2*8
> > +/* #define SGX_ENCLAVE_RUN_USER_DATA	3*8 */
> 
> What's with that guy? Left here as documentation showing what's at 3*8
> offset?

Yes.

> > +#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
> > +
> > +#define SGX_SYNCHRONOUS_EXIT		0
> > +#define SGX_EXCEPTION_EXIT		1
> 
> Those are in ...uapi/asm/sgx.h too. Unify?

I have not authored this patch but what I would propose is to use just
raw value in the place of these constants. It is practially just a
boolean value.

I can also add sgx_vdso.h to uapi directory. I just don't see the point.

Holding on for feedback with this one.

> > +
> > +/* Offsets into sgx_enter_enclave.exception. */
> > +#define SGX_EX_LEAF			0*8
> > +#define SGX_EX_TRAPNR			0*8+4
> > +#define SGX_EX_ERROR_CODE		0*8+6
> > +#define SGX_EX_ADDRESS			1*8
> > +
> > +.code64
> > +.section .text, "ax"
> > +
> > +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > +	/* Prolog */
> > +	.cfi_startproc
> 
> Are the CFI annotations for userspace?

Yes, for stack unwinding. However, I would leave them out. Holding on
for further feedback with this tho.

> > +	push	%rbp
> > +	.cfi_adjust_cfa_offset	8
> > +	.cfi_rel_offset		%rbp, 0
> > +	mov	%rsp, %rbp
> > +	.cfi_def_cfa_register	%rbp
> > +	push	%rbx
> > +	.cfi_rel_offset		%rbx, -8
> > +
> > +	mov	%ecx, %eax
> > +.Lenter_enclave:
> > +	/* EENTER <= leaf <= ERESUME */
> > +	cmp	$EENTER, %eax
> > +	jb	.Linvalid_input
> > +	cmp	$ERESUME, %eax
> > +	ja	.Linvalid_input
> > +
> > +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rcx
> > +
> > +	/* No flags are currently defined/supported. */
> > +	cmpl	$0, SGX_ENCLAVE_RUN_FLAGS(%rcx)
> > +	jne	.Linvalid_input
> > +
> > +	/* Load TCS and AEP */
> 
> 		TSC
> 
> I can see why you would write "TCS" though - there's a thread control
> structure thing too in that patch.

Renamed.

> > +	mov	SGX_ENCLAVE_RUN_TSC(%rcx), %rbx
> > +	lea	.Lasync_exit_pointer(%rip), %rcx
> > +
> > +	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
> > +.Lasync_exit_pointer:
> > +.Lenclu_eenter_eresume:
> > +	enclu
> > +
> > +	/* EEXIT jumps here unless the enclave is doing something fancy. */
> > +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
> > +
> > +	/* Set exit_reason. */
> > +	movl	$SGX_SYNCHRONOUS_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
> > +
> > +	/* Invoke userspace's exit handler if one was provided. */
> > +.Lhandle_exit:
> > +	cmpq	$0, SGX_ENCLAVE_RUN_USER_HANDLER(%rbx)
> > +	jne	.Linvoke_userspace_handler
> > +
> > +	/* Success, in the sense that ENCLU was attempted. */
> > +	xor	%eax, %eax
> > +
> > +.Lout:
> > +	pop	%rbx
> > +	leave
> > +	.cfi_def_cfa		%rsp, 8
> > +	ret
> > +
> > +	/* The out-of-line code runs with the pre-leave stack frame. */
> > +	.cfi_def_cfa		%rbp, 16
> > +
> > +.Linvalid_input:
> > +	mov	$(-EINVAL), %eax
> > +	jmp	.Lout
> > +
> > +.Lhandle_exception:
> > +	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
> > +
> > +	/* Set the exit_reason and exception info. */
> > +	movl	$SGX_EXCEPTION_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
> > +
> > +	mov	%eax, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_LEAF)(%rbx)
> > +	mov	%di,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_TRAPNR)(%rbx)
> > +	mov	%si,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ERROR_CODE)(%rbx)
> > +	mov	%rdx, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ADDRESS)(%rbx)
> > +	jmp	.Lhandle_exit
> > +
> > +.Linvoke_userspace_handler:
> > +	/* Pass the untrusted RSP (at exit) to the callback via %rcx. */
> > +	mov	%rsp, %rcx
> > +
> > +	/* Save @e, %rbx is about to be clobbered. */
> 
> I've been wondering what that "@e" thing is and I believe I've found it at the
> end: "... @e, the optional sgx_enclave_exception struct"
> 
> Yes?
> 
> Please rewrite what that "e" is here - I think you wanna say "struct
> sgx_enclave_run.exception" instead to clarify.

I agree. Open coded them as "struct sgx_enclave_exception".

> 
> ...
> 
> > diff --git a/arch/x86/include/asm/enclu.h b/arch/x86/include/asm/enclu.h
> > new file mode 100644
> > index 000000000000..06157b3e9ede
> > --- /dev/null
> > +++ b/arch/x86/include/asm/enclu.h
> > @@ -0,0 +1,8 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_X86_ENCLU_H
> > +#define _ASM_X86_ENCLU_H
> > +
> > +#define EENTER	0x02
> > +#define ERESUME	0x03
> > +
> > +#endif /* _ASM_X86_ENCLU_H */
> > diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
> > index d0916fb9629e..1564d7f88597 100644
> > --- a/arch/x86/include/uapi/asm/sgx.h
> > +++ b/arch/x86/include/uapi/asm/sgx.h
> 
> Are all those defines being added to the uapi header, also actually
> needed by userspace?

I'd remove the two constants, as it is clearly just a boolean value.

> > @@ -72,4 +72,132 @@ struct sgx_enclave_provision {
> >  	__u64 attribute_fd;
> >  };
> >  
> > +#define SGX_SYNCHRONOUS_EXIT	0
> > +#define SGX_EXCEPTION_EXIT	1
> > +
> > +struct sgx_enclave_run;
> > +
> > +/**
> > + * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
> > + *					__vdso_sgx_enter_enclave()
> > + *
> > + * @rdi:	RDI at the time of enclave exit
> > + * @rsi:	RSI at the time of enclave exit
> > + * @rdx:	RDX at the time of enclave exit
> > + * @ursp:	RSP at the time of enclave exit (untrusted stack)
> > + * @r8:		R8 at the time of enclave exit
> > + * @r9:		R9 at the time of enclave exit
> 
> I'm sure you can avoid that "at the time of enclave exit" repetition.

I edited this as

/**
 * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
 *					__vdso_sgx_enter_enclave()
 * @rdi:	RDI snapshot
 * @rsi:	RSI snapshot
 * @rdx:	RDX snapshot
 * @rsp:	RSP snapshot (untrusted stack)
 * @r8:		R8 snapshot
 * @r9:		R9 snapshot
 * @run:	Pointer to the caller provided struct sgx_enclave_run
 *
 * Return:
 *  0 or negative to exit vDSO
 *  positive to re-enter enclave (must be EENTER or ERESUME leaf)
 */
typedef int (*sgx_enclave_exit_handler_t)(long rdi, long rsi, long rdx,
					  long rsp, long r8, long r9,
					  struct sgx_enclave_run *run);


> > +/**
> > + * typedef vdso_sgx_enter_enclave_t - Prototype for __vdso_sgx_enter_enclave(),
> > + *				      a vDSO function to enter an SGX enclave.
> > + *
> > + * @rdi:	Pass-through value for RDI
> > + * @rsi:	Pass-through value for RSI
> > + * @rdx:	Pass-through value for RDX
> > + * @leaf:	ENCLU leaf, must be EENTER or ERESUME
> > + * @r8:		Pass-through value for R8
> > + * @r9:		Pass-through value for R9
> > + * @r:		struct sgx_enclave_run, must be non-NULL
> > + *
> > + * NOTE: __vdso_sgx_enter_enclave() does not ensure full compliance with the
> > + * x86-64 ABI, e.g. doesn't handle XSAVE state.  Except for non-volatile
> > + * general purpose registers, EFLAGS.DF, and RSP alignment, preserving/setting
> > + * state in accordance with the x86-64 ABI is the responsibility of the enclave
> > + * and its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C
> > + * code without careful consideration by both the enclave and its runtime.
> > + *
> > + * All general purpose registers except RAX, RBX and RCX are passed as-is to
> > + * the enclave.  RAX, RBX and RCX are consumed by EENTER and ERESUME and are
> > + * loaded with @leaf, asynchronous exit pointer, and @tcs respectively.
> 
> That tcs is probably struct sgx_enclave_run.tcs?

Yes.

> > + * RBP and the stack are used to anchor __vdso_sgx_enter_enclave() to the
> > + * pre-enclave state, e.g. to retrieve @e and @handler after an enclave exit.
> 
> Expand @e and do you mean "@user_handler" with "@handler"?

I replaced this and similar fields as @run.user_handler and so forth.

> 
> > + * All other registers are available for use by the enclave and its runtime,
> > + * e.g. an enclave can push additional data onto the stack (and modify RSP) to
> > + * pass information to the optional exit handler (see below).
> > + *
> > + * Most exceptions reported on ENCLU, including those that occur within the
> > + * enclave, are fixed up and reported synchronously instead of being delivered
> > + * via a standard signal. Debug Exceptions (#DB) and Breakpoints (#BP) are
> > + * never fixed up and are always delivered via standard signals. On synchrously
> > + * reported exceptions, -EFAULT is returned and details about the exception are
> > + * recorded in @e, the optional sgx_enclave_exception struct.
> > + *
> > + * If an exit handler is provided, the handler will be invoked on synchronous
> > + * exits from the enclave and for all synchronously reported exceptions. In
> > + * latter case, @e is filled prior to invoking the handler.
> > + *
> > + * The exit handler's return value is interpreted as follows:
> > + *  >0:		continue, restart __vdso_sgx_enter_enclave() with @ret as @leaf
> > + *   0:		success, return @ret to the caller
> > + *  <0:		error, return @ret to the caller
> > + *
> > + * The exit handler may transfer control, e.g. via longjmp() or C++ exception,
> > + * without returning to __vdso_sgx_enter_enclave().
> > + *
> > + * Return:
> > + *  0 on success (ENCLU reached),
> > + *  -EINVAL if ENCLU leaf is not allowed,
> > + *  -errno for all other negative values returned by the userspace exit handler
> > + */
> > +typedef int (*vdso_sgx_enter_enclave_t)(unsigned long rdi, unsigned long rsi,
> > +					unsigned long rdx, unsigned int leaf,
> > +					unsigned long r8,  unsigned long r9,
> > +					struct sgx_enclave_run *r);
> > +
> >  #endif /* _UAPI_ASM_X86_SGX_H */
> > -- 
> > 2.25.1
> > 
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Also, I renamed 'r' as 'run' in some places.

End result:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h

I'm wondering this sentence:

"The calling convention is custom and does not follow System V x86-64 ABI."

AFAIK, now the vDSO is fully C-callable but waiting for feedback before
removing it.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
       [not found]     ` <20200925003808.GB20333@linux.intel.com>
@ 2020-09-25  1:04       ` Jarkko Sakkinen
  2020-09-25  8:14       ` Borislav Petkov
  2020-09-28 14:36       ` Jarkko Sakkinen
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25  1:04 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 05:38:10PM -0700, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 08:04:07PM +0200, Borislav Petkov wrote:
> > On Tue, Sep 15, 2020 at 02:28:39PM +0300, Jarkko Sakkinen wrote:
> > > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > new file mode 100644
> > > index 000000000000..adbd59d41517
> > > --- /dev/null
> > > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > 
> > Why not simply
> > 
> > arch/x86/entry/vdso/sgx.S
> > 
> > ?
> 
> I really like typing?

I fixed bunch of things. For that sentence I need feedback + for any
other possible changes please send a patch if required.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-24 20:38             ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver' Jarkko Sakkinen
  2020-09-24 20:40               ` Jarkko Sakkinen
@ 2020-09-25  7:51               ` Borislav Petkov
  2020-09-25 11:21                 ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-25  7:51 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Thu, Sep 24, 2020 at 11:38:59PM +0300, Jarkko Sakkinen wrote:
> I assume this is a rethorical question

Of course - our text should not be write-only.

> and I notice what I suggested
> looks as bad as my earlier commit message :-)
> 
> So, I gave it some thought that and decided to "open code" the paragraph
> as
> 
> "Add sgx_vma_access() function that implements 'access' virtual function
> of struct vm_operations_struct. Use formentioned leaf instructions to

"aforementioned"

> achieve read and write primitives for the enclave memory."

I'd say "to provide read and write access to enclave memory."

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-24 20:40               ` Jarkko Sakkinen
@ 2020-09-25  7:53                 ` Borislav Petkov
  2020-09-25 11:00                   ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-25  7:53 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Thu, Sep 24, 2020 at 11:40:22PM +0300, Jarkko Sakkinen wrote:
> I'm not sure if I said it already but I also added cc to linux-mm (same
> CC's in the patch as with mprotect callback commit). This should also
> have mm ack I think.

Why? This is adding ptrace functionality to enclaves which is purely
arch/x86/.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
       [not found]     ` <20200925003808.GB20333@linux.intel.com>
  2020-09-25  1:04       ` Jarkko Sakkinen
@ 2020-09-25  8:14       ` Borislav Petkov
  2020-09-25 10:59         ` Jarkko Sakkinen
  2020-09-28 14:36       ` Jarkko Sakkinen
  2 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-25  8:14 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Jarkko Sakkinen, x86, linux-sgx, linux-kernel, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 05:38:10PM -0700, Sean Christopherson wrote:
> > Why not simply
> > 
> > arch/x86/entry/vdso/sgx.S
> > 
> > ?
> 
> I really like typing?

I'll say.

> Yes, to call out that there's a field there, but a field that the vDSO should
> never touch.

You wanna enforce that in the vdso code?

Because if it is there, luserspace will touch it.

> > > +#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
> > > +
> > > +#define SGX_SYNCHRONOUS_EXIT		0
> > > +#define SGX_EXCEPTION_EXIT		1
> > 
> > Those are in ...uapi/asm/sgx.h too. Unify?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What about this here?

> > Are the CFI annotations for userspace?
> 
> Yes, though that's a 90% confident "yes".

Looks like we wanna support it:

f24f91088427 ("x86/vdso: Define BUILD_VDSO while building and emit .eh_frame in asm")

> Argh, it's actually supposed to be TCS, SGX_ENCLAVE_RUN_TSC is the one that's
> wrong.

Whoopsie :-)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25  1:00     ` Jarkko Sakkinen
@ 2020-09-25  8:28       ` Borislav Petkov
  2020-09-27 23:37         ` Jarkko Sakkinen
  2020-09-25  8:39       ` Jethro Beekman
  1 sibling, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-25  8:28 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Fri, Sep 25, 2020 at 04:00:40AM +0300, Jarkko Sakkinen wrote:
> I renamed it as vsgx.S (for the sake of convention).

Right.

> I have not authored this patch but what I would propose is to use just
> raw value in the place of these constants. It is practially just a
> boolean value.
> 
> I can also add sgx_vdso.h to uapi directory. I just don't see the point.

Just be very cautious what you add to the uapi/ directory because it
becomes API and there's no changing it. That's why I point you guys to
it, to think hard what you expose there and that it becomes contract
with luserspace.

> > I can see why you would write "TCS" though - there's a thread control
> > structure thing too in that patch.
> 
> Renamed.

See Sean's reply.

> /**
>  * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
>  *					__vdso_sgx_enter_enclave()
>  * @rdi:	RDI snapshot
>  * @rsi:	RSI snapshot
>  * @rdx:	RDX snapshot
>  * @rsp:	RSP snapshot (untrusted stack)
>  * @r8:		R8 snapshot
>  * @r9:		R9 snapshot

I'd say here:

"The registers' content is the snapshot made at enclave exit."

> Also, I renamed 'r' as 'run' in some places.
> 
> End result:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
> 
> I'm wondering this sentence:
> 
> "The calling convention is custom and does not follow System V x86-64 ABI."

Yeah, I was wondering what that meant too.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25  1:00     ` Jarkko Sakkinen
  2020-09-25  8:28       ` Borislav Petkov
@ 2020-09-25  8:39       ` Jethro Beekman
  2020-09-25 11:17         ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Jethro Beekman @ 2020-09-25  8:39 UTC (permalink / raw)
  To: Jarkko Sakkinen, Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Cedric Xing, akpm, andriy.shevchenko, asapek,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx


[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On 2020-09-25 03:00, Jarkko Sakkinen wrote:
> End result:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
> 
> I'm wondering this sentence:
> 
> "The calling convention is custom and does not follow System V x86-64 ABI."
> 
> AFAIK, now the vDSO is fully C-callable but waiting for feedback before
> removing it.

It's C-callable *iff your enclave follows the System V x86-64 ABI*. In addition, all registers not clobbered by the SGX ISA are passed to the enclave, not just those specified as parameter passing registers in the ABI. This is intentional to make the vDSO function usable in applications that use the current flexibility of ENCLU.

--
Jethro Beekman | Fortanix



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25  8:14       ` Borislav Petkov
@ 2020-09-25 10:59         ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25 10:59 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Sean Christopherson, x86, linux-sgx, linux-kernel,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Fri, Sep 25, 2020 at 10:14:41AM +0200, Borislav Petkov wrote:
> > > > +#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
> > > > +
> > > > +#define SGX_SYNCHRONOUS_EXIT		0
> > > > +#define SGX_EXCEPTION_EXIT		1
> > > 
> > > Those are in ...uapi/asm/sgx.h too. Unify?
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> What about this here?

Repeating myself, but since there is only 0 and 1, I would just use 0
and 1.

Otherwise, I think I pretty much got these comments sorted out.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-25  7:53                 ` Borislav Petkov
@ 2020-09-25 11:00                   ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25 11:00 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Fri, Sep 25, 2020 at 09:53:01AM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 11:40:22PM +0300, Jarkko Sakkinen wrote:
> > I'm not sure if I said it already but I also added cc to linux-mm (same
> > CC's in the patch as with mprotect callback commit). This should also
> > have mm ack I think.
> 
> Why? This is adding ptrace functionality to enclaves which is purely
> arch/x86/.

You are right. No changes to vm_operations_struct itself.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25  8:39       ` Jethro Beekman
@ 2020-09-25 11:17         ` Jarkko Sakkinen
  2020-09-25 11:43           ` Jethro Beekman
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25 11:17 UTC (permalink / raw)
  To: Jethro Beekman
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel,
	Sean Christopherson, Andy Lutomirski, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Fri, Sep 25, 2020 at 10:39:58AM +0200, Jethro Beekman wrote:
> On 2020-09-25 03:00, Jarkko Sakkinen wrote:
> > End result:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
> > 
> > I'm wondering this sentence:
> > 
> > "The calling convention is custom and does not follow System V x86-64 ABI."
> > 
> > AFAIK, now the vDSO is fully C-callable but waiting for feedback before
> > removing it.
> 
> It's C-callable *iff your enclave follows the System V x86-64 ABI*. In
> addition, all registers not clobbered by the SGX ISA are passed to the
> enclave, not just those specified as parameter passing registers in
> the ABI. This is intentional to make the vDSO function usable in
> applications that use the current flexibility of ENCLU.

Hold on, I really want to fix this bit of documentation before sending
any new version, so I'll explain how I understand it.

I think it is just SystemV ABI call with six parameters in the usual
GPRs (rdi, rsi, rdx, rcx, r8, r9).

I'm looking at vdso_sgx_enter_enclave.

What I'm not getting?

> --
> Jethro Beekman | Fortanix

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver'
  2020-09-25  7:51               ` Borislav Petkov
@ 2020-09-25 11:21                 ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-25 11:21 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, akpm,
	andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx

On Fri, Sep 25, 2020 at 09:51:04AM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 11:38:59PM +0300, Jarkko Sakkinen wrote:
> > I assume this is a rethorical question
> 
> Of course - our text should not be write-only.
> 
> > and I notice what I suggested
> > looks as bad as my earlier commit message :-)
> > 
> > So, I gave it some thought that and decided to "open code" the paragraph
> > as
> > 
> > "Add sgx_vma_access() function that implements 'access' virtual function
> > of struct vm_operations_struct. Use formentioned leaf instructions to
> 
> "aforementioned"

Ugh, that the was worst spelling I've done for a while.

> > achieve read and write primitives for the enclave memory."
> 
> I'd say "to provide read and write access to enclave memory."

Sound better yes, thanks.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Updated the commit message accordingly. I also rebased now to x86
tip (and yes, merge conflicts were trivial to sort out).

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25 11:17         ` Jarkko Sakkinen
@ 2020-09-25 11:43           ` Jethro Beekman
  0 siblings, 0 replies; 180+ messages in thread
From: Jethro Beekman @ 2020-09-25 11:43 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel,
	Sean Christopherson, Andy Lutomirski, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx


[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

On 2020-09-25 13:17, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 10:39:58AM +0200, Jethro Beekman wrote:
>> On 2020-09-25 03:00, Jarkko Sakkinen wrote:
>>> End result:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
>>>
>>> I'm wondering this sentence:
>>>
>>> "The calling convention is custom and does not follow System V x86-64 ABI."
>>>
>>> AFAIK, now the vDSO is fully C-callable but waiting for feedback before
>>> removing it.
>>
>> It's C-callable *iff your enclave follows the System V x86-64 ABI*. In
>> addition, all registers not clobbered by the SGX ISA are passed to the
>> enclave, not just those specified as parameter passing registers in
>> the ABI. This is intentional to make the vDSO function usable in
>> applications that use the current flexibility of ENCLU.
> 
> Hold on, I really want to fix this bit of documentation before sending
> any new version, so I'll explain how I understand it.
> 
> I think it is just SystemV ABI call with six parameters in the usual
> GPRs (rdi, rsi, rdx, rcx, r8, r9).
> 
> I'm looking at vdso_sgx_enter_enclave.
> 
> What I'm not getting?

This can't be observed from looking at the code in vdso_sgx_enter_enclave, because what makes this "custom" is the absence of code or code in the enclave.

If you call vdso_sgx_enter_enclave() from C but your enclave doesn't respect the ABI (for example, it clobbers callee-saved registers), your code will break. But if you call vdso_sgx_enter_enclave from assembly, you can use enclaves with any ABI as long as your assembly and the enclave agree on that ABI.

Alternatively, when using assembly, I can pass stuff to the enclave in registers besides rdi, rsi, rdx, rcx, r8, r9, just as if I were manually calling ENCLU from assembly.

The vDSO assembly has been carefully written to support both scenarios by only using rax, rbx, rcx, rbp, rsp and passing rdi, rsi, rdx, r8, r9 (and everything else).

> + * NOTE: __vdso_sgx_enter_enclave() does not ensure full compliance with the
> + * x86-64 ABI, e.g. doesn't handle XSAVE state.  Except for non-volatile
> + * general purpose registers, EFLAGS.DF, and RSP alignment, preserving/setting
> + * state in accordance with the x86-64 ABI is the responsibility of the enclave
> + * and its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C
> + * code without careful consideration by both the enclave and its runtime.
> + *
> + * All general purpose registers except RAX, RBX and RCX are passed as-is to
> + * the enclave.  RAX, RBX and RCX are consumed by EENTER and ERESUME and are
> + * loaded with @leaf, asynchronous exit pointer, and @tcs respectively.

Perhaps this should be updated to read "All general purpose registers except RAX, RBX, RCX, RBP and RSP ..."

--
Jethro Beekman | Fortanix


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-25  0:00                                         ` Sean Christopherson
@ 2020-09-25 17:18                                           ` Dave Hansen
  2020-09-25 19:43                                             ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-25 17:18 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

Thanks for the walkthrough.  The thing that clicked for me seeing those
examples was how the earlier ioctl(ADD_PAGE) is "bound" to later
enforcement actions at enclave PTE creation time.

On 9/24/20 5:00 PM, Sean Christopherson wrote:
> My concern is that if we merge this
> 
>         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
> 
> without ->mprotect(), we can't actually enforce the declared protections.  And
> if we drop the field altogether:
> 
>         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
> 
> then we can't implement security_enclave_load().

To me, it's perfectly OK to have parts of the ABI which are unused.  It
sure makes them harder to test if there are no actual users in the code,
but if it solves a real problem with the ABI, I'm fine with it.

Let's see if I can put all the pieces together.

Background:

1. SGX enclave pages are populated with data by copying data to them
   from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...);
2. We want to be able to restrict those normal memory data sources.  For
   instance, before copying data to an executable enclave page, we might
   ensure that the source is executable.
3. Enclave page permissions are dynamic just like normal permissions and
   can be adjusted at runtime with mprotect() (along with a
   corresponding special instruction inside the enclave)
4. The original data source may have have long since vanished at the
   time when enclave page permission are established (mmap() or
   mprotect())

Solution:

The solution is to force enclaves creators to declare their intent up
front to ioctl(ENCLAVE_ADD_PAGE).  This intent can me immediately
compared to the source data mapping (and rejected if necessary).  It is
also stashed off and then later compared with enclave PTEs to ensure
that any future mmap()/mprotect() operations performed by the enclave
creator or the enclave itself are consistent with the earlier declared
permissions.

Essentially, this means that whenever the kernel is asked to change an
enclave PTE, it needs to ensure the change is consistent with that
stashed intent.  There is an existing vm_ops->mmap() hook which allows
SGX to do that for mmap().  However, there is no ->mprotect() hook.  Add
a vm_ops->mprotect() hook so that mprotect() operations which are
inconsistent with any page's stashed intent can be rejected by the driver.

Implications:

However, there is currently no implementation of the intent checks at
the time of ioctl(ENCLAVE_ADD_PAGE).  That means that the intent
argument (SGX_PROT_*) is currently unused.

--

Is that all correct?  Did I miss anything?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-15 11:28 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
  2020-09-24 18:04   ` Borislav Petkov
@ 2020-09-25 18:23   ` Andrew Cooper
  2020-09-28  0:58     ` Jarkko Sakkinen
  2020-09-28 15:43     ` Yu, Yu-cheng
  1 sibling, 2 replies; 180+ messages in thread
From: Andrew Cooper @ 2020-09-25 18:23 UTC (permalink / raw)
  To: Jarkko Sakkinen, x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek, bp,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx, H.J. Lu,
	Yu-cheng Yu

On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> new file mode 100644
> index 000000000000..adbd59d41517
> --- /dev/null
> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> @@ -0,0 +1,157 @@
> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> <snip>
> +.Lretpoline:
> +	call	2f
> +1:	pause
> +	lfence
> +	jmp	1b
> +2:	mov	%rax, (%rsp)
> +	ret

I hate to throw further spanners in the work, but this is not compatible
with CET, and the user shadow stack work in progress.

Whichever of these two large series lands first is going to inflict
fixing this problem on the other.

As the vdso text is global (to a first approximation), it must not be a
retpoline if any other process is liable to want to use CET-SS.

If the retpoline really does need to stay, then the vdso probably needs
to gain suitable __x86_indirect_thunk_%reg thunks which are patched at
boot based on the system properties.

~Andrew

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-25 17:18                                           ` Dave Hansen
@ 2020-09-25 19:43                                             ` Sean Christopherson
  2020-09-25 19:53                                               ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-25 19:43 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Fri, Sep 25, 2020 at 10:18:28AM -0700, Dave Hansen wrote:
> Thanks for the walkthrough.  The thing that clicked for me seeing those
> examples was how the earlier ioctl(ADD_PAGE) is "bound" to later
> enforcement actions at enclave PTE creation time.
> 
> On 9/24/20 5:00 PM, Sean Christopherson wrote:
> > My concern is that if we merge this
> > 
> >         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
> > 
> > without ->mprotect(), we can't actually enforce the declared protections.  And
> > if we drop the field altogether:
> > 
> >         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
> > 
> > then we can't implement security_enclave_load().
> 
> To me, it's perfectly OK to have parts of the ABI which are unused.  It
> sure makes them harder to test if there are no actual users in the code,
> but if it solves a real problem with the ABI, I'm fine with it.
> 
> Let's see if I can put all the pieces together.
> 
> Background:
> 
> 1. SGX enclave pages are populated with data by copying data to them
>    from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...);
> 2. We want to be able to restrict those normal memory data sources.  For
>    instance, before copying data to an executable enclave page, we might
>    ensure that the source is executable.
> 3. Enclave page permissions are dynamic just like normal permissions and
>    can be adjusted at runtime with mprotect() (along with a
>    corresponding special instruction inside the enclave)
> 4. The original data source may have have long since vanished at the
>    time when enclave page permission are established (mmap() or
>    mprotect())
> 
> Solution:
> 
> The solution is to force enclaves creators to declare their intent up
> front to ioctl(ENCLAVE_ADD_PAGE).  This intent can me immediately
> compared to the source data mapping (and rejected if necessary).  It is
> also stashed off and then later compared with enclave PTEs to ensure
> that any future mmap()/mprotect() operations performed by the enclave
> creator or the enclave itself are consistent with the earlier declared
> permissions.
> 
> Essentially, this means that whenever the kernel is asked to change an
> enclave PTE, it needs to ensure the change is consistent with that
> stashed intent.  There is an existing vm_ops->mmap() hook which allows
> SGX to do that for mmap().  However, there is no ->mprotect() hook.  Add
> a vm_ops->mprotect() hook so that mprotect() operations which are
> inconsistent with any page's stashed intent can be rejected by the driver.

Yes to all of the above.

> Implications:
> 
> However, there is currently no implementation of the intent checks at
> the time of ioctl(ENCLAVE_ADD_PAGE).

Correct.

> That means that the intent argument (SGX_PROT_*) is currently unused.

No, the intent argument is used (eventually) by SGX's ->mprotect()
implementation, i.e. sgx_mprotect() enforces that the actual protections are a
subset of the declared/intended protections.

If ->mprotect() is not merged, then it yes, it will be unused.  And therein
lies the problem as the kernel can't start using/enforcing the intent without
breaking userspace.  E.g. an enclave loaded with SGX_PROT_READ but mprotect()'d
with PROT_READ | PROT_EXEC would break if sgx_mprotect() came along.

One way to avoid introducing ->mprotect() would be to require all enclaves to
declare all pages with READ|WRITE|EXEC.  Then we could drop sgx_mprotect()
since the mprotect() permissions are guaranteed to be a subset of the declared
permissions.  That would have the added bonus of eliminating the per-page
checks in sgx_mmap()/sgx_mprotect(), though I've no idea if that is a
meaningful optmization or it's lost in the noise.

The big downside of requiring READ|WRITE|EXEC is that it will make life hell
for a LSM policy owner if they ever want to apply EXECMEM or EXECMOD style
restritions on enclaves, i.e. if SELinux folks want to add
security_enclave_load().

I find that I'm more or less ok with that approach, in no small part because
introducing security_enclave_load() might be a pretty big "if", e.g. security
folks may decide that they'd rather allow/deny enclaves based on the
measurement or signer of the enclave and eschew per-page checks entirely.

> --
> 
> Is that all correct?  Did I miss anything?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-25 19:43                                             ` Sean Christopherson
@ 2020-09-25 19:53                                               ` Dave Hansen
  2020-09-26  4:15                                                 ` Andy Lutomirski
  2020-09-28  0:53                                                 ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-25 19:53 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Haitao Huang, Jarkko Sakkinen, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/25/20 12:43 PM, Sean Christopherson wrote:
>> That means that the intent argument (SGX_PROT_*) is currently unused.
> No, the intent argument is used (eventually) by SGX's ->mprotect()
> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> subset of the declared/intended protections.
> 
> If ->mprotect() is not merged, then it yes, it will be unused.

OK, I think I've got it.

I think I'm OK with adding ->mprotect().  As long as folks buy into the
argument that intent needs to be checked at mmap() time, they obviously
need to be checked at mprotect() too.

Jarkko, if you want to try and rewrite the changelog, capturing the
discussion here and reply, I think I can ack the resulting patch.  I
don't know if that will satisfy the request from Boris from an ack from
a "mm person", but we can at least start there. :)

Please be judicious in what you include in the changelog.  There's been
a lot of detritus in them.  Let's keep it as short, sweet, simple and on
topic as we can.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 24/24] x86/sgx: Update MAINTAINERS
  2020-09-15 11:28 ` [PATCH v38 24/24] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
@ 2020-09-25 22:37   ` Sean Christopherson
  2020-09-28  0:44     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-25 22:37 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Thomas Gleixner, Borislav Petkov,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, yaozhangx

On Tue, Sep 15, 2020 at 02:28:42PM +0300, Jarkko Sakkinen wrote:
> Add the maintainer information for the SGX subsystem.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  MAINTAINERS | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3b186ade3597..1d4daeb12d0a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9051,6 +9051,17 @@ F:	Documentation/x86/intel_txt.rst
>  F:	arch/x86/kernel/tboot.c
>  F:	include/linux/tboot.h
>  
> +INTEL SGX
> +M:	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> +M:	Sean Christopherson <sean.j.christopherson@intel.com>
> +L:	linux-sgx@vger.kernel.org
> +S:	Maintained
> +Q:	https://patchwork.kernel.org/project/intel-sgx/list/
> +T:	git https://github.com/jsakkine-intel/linux-sgx.git

This is stale, you moved your tree to kernel.org.

> +F:	arch/x86/include/uapi/asm/sgx.h
> +F:	arch/x86/kernel/cpu/sgx/*
> +K:	\bSGX_
> +
>  INTERCONNECT API
>  M:	Georgi Djakov <georgi.djakov@linaro.org>
>  L:	linux-pm@vger.kernel.org
> -- 
> 2.25.1
> 

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-25 19:53                                               ` Dave Hansen
@ 2020-09-26  4:15                                                 ` Andy Lutomirski
  2020-09-28  0:53                                                 ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-26  4:15 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Jarkko Sakkinen,
	Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx


> On Sep 25, 2020, at 12:53 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> 
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
>>> That means that the intent argument (SGX_PROT_*) is currently unused.
>> No, the intent argument is used (eventually) by SGX's ->mprotect()
>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
>> subset of the declared/intended protections.
>> 
>> If ->mprotect() is not merged, then it yes, it will be unused.
> 
> OK, I think I've got it.
> 
> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> argument that intent needs to be checked at mmap() time, they obviously
> need to be checked at mprotect() too.
> 
> Jarkko, if you want to try and rewrite the changelog, capturing the
> discussion here and reply, I think I can ack the resulting patch.  I
> don't know if that will satisfy the request from Boris from an ack from
> a "mm person", but we can at least start there. :)

I think I agree. ->mprotect seems reasonable to me.

FWIW, I don’t think I should ack this particular thing — it was, to a decent extent, my suggestion in the first place, so I’m biased. I think it turned into something reasonable, and the ->mprotect mechanism seems easily supportable and plausibly useful for other purposes down the road.

> 
> Please be judicious in what you include in the changelog.  There's been
> a lot of detritus in them.  Let's keep it as short, sweet, simple and on
> topic as we can.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25  8:28       ` Borislav Petkov
@ 2020-09-27 23:37         ` Jarkko Sakkinen
  2020-09-28  8:30           ` Borislav Petkov
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-27 23:37 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Fri, Sep 25, 2020 at 10:28:07AM +0200, Borislav Petkov wrote:
> > > I can see why you would write "TCS" though - there's a thread control
> > > structure thing too in that patch.
> > 
> > Renamed.
> 
> See Sean's reply.

I did not get Sean's reply, and neither can find it from lore:

https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#t

> >  * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
> >  *					__vdso_sgx_enter_enclave()
> >  * @rdi:	RDI snapshot
> >  * @rsi:	RSI snapshot
> >  * @rdx:	RDX snapshot
> >  * @rsp:	RSP snapshot (untrusted stack)
> >  * @r8:		R8 snapshot
> >  * @r9:		R9 snapshot
> 
> I'd say here:
> 
> "The registers' content is the snapshot made at enclave exit."

I'd make that a description and take away individual parameter
descriptions. Is that fine?

> > Also, I renamed 'r' as 'run' in some places.
> > 
> > End result:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
> > 
> > I'm wondering this sentence:
> > 
> > "The calling convention is custom and does not follow System V x86-64 ABI."
> 
> Yeah, I was wondering what that meant too.

I'll refine that one based on my own and Jethro's feedback.

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 24/24] x86/sgx: Update MAINTAINERS
  2020-09-25 22:37   ` Sean Christopherson
@ 2020-09-28  0:44     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28  0:44 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: x86, linux-sgx, linux-kernel, Thomas Gleixner, Borislav Petkov,
	akpm, andriy.shevchenko, asapek, cedric.xing, chenalexchen,
	conradparker, cyhanish, dave.hansen, haitao.huang, josh,
	kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman, npmccallum,
	puiterwijk, rientjes, yaozhangx

On Fri, Sep 25, 2020 at 03:37:54PM -0700, Sean Christopherson wrote:
> On Tue, Sep 15, 2020 at 02:28:42PM +0300, Jarkko Sakkinen wrote:
> > Add the maintainer information for the SGX subsystem.
> > 
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> >  MAINTAINERS | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3b186ade3597..1d4daeb12d0a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9051,6 +9051,17 @@ F:	Documentation/x86/intel_txt.rst
> >  F:	arch/x86/kernel/tboot.c
> >  F:	include/linux/tboot.h
> >  
> > +INTEL SGX
> > +M:	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > +M:	Sean Christopherson <sean.j.christopherson@intel.com>
> > +L:	linux-sgx@vger.kernel.org
> > +S:	Maintained
> > +Q:	https://patchwork.kernel.org/project/intel-sgx/list/
> > +T:	git https://github.com/jsakkine-intel/linux-sgx.git
> 
> This is stale, you moved your tree to kernel.org.

That's correct. It is already updated in my GIT tree:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/MAINTAINERS

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-25 19:53                                               ` Dave Hansen
  2020-09-26  4:15                                                 ` Andy Lutomirski
@ 2020-09-28  0:53                                                 ` Jarkko Sakkinen
  2020-09-28 14:04                                                   ` Dave Hansen
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28  0:53 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >> That means that the intent argument (SGX_PROT_*) is currently unused.
> > No, the intent argument is used (eventually) by SGX's ->mprotect()
> > implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> > subset of the declared/intended protections.
> > 
> > If ->mprotect() is not merged, then it yes, it will be unused.
> 
> OK, I think I've got it.
> 
> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> argument that intent needs to be checked at mmap() time, they obviously
> need to be checked at mprotect() too.
> 
> Jarkko, if you want to try and rewrite the changelog, capturing the
> discussion here and reply, I think I can ack the resulting patch.  I
> don't know if that will satisfy the request from Boris from an ack from
> a "mm person", but we can at least start there. :)

I think what it needs, based on what I've read, is the step by step
description of the EMODPE scenarion without this callback and with it.

I think other important thing to underline is that an LSM or any other
security measure can only do a sane decision when the enclave is loaded.
At that point we know the source (vm_file).

I.e. when you are doing mmap() or mprotect() you don't have that
information. The permissions kind of describe the contact made at that
point of time.

> Please be judicious in what you include in the changelog.  There's been
> a lot of detritus in them.  Let's keep it as short, sweet, simple and on
> topic as we can.

Of course.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25 18:23   ` Andrew Cooper
@ 2020-09-28  0:58     ` Jarkko Sakkinen
  2020-09-28 16:44       ` Andrew Cooper
  2020-09-28 15:43     ` Yu, Yu-cheng
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28  0:58 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu, Yu-cheng Yu

On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > new file mode 100644
> > index 000000000000..adbd59d41517
> > --- /dev/null
> > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > @@ -0,0 +1,157 @@
> > +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > <snip>
> > +.Lretpoline:
> > +	call	2f
> > +1:	pause
> > +	lfence
> > +	jmp	1b
> > +2:	mov	%rax, (%rsp)
> > +	ret
> 
> I hate to throw further spanners in the work, but this is not compatible
> with CET, and the user shadow stack work in progress.

CET goes beyond my expertise. Can you describe, at least rudimentary,
how this code is not compatible?

I know CET only conceptual level (separate stack holding return
addresses as an measure against return oriented programming (ROP)).

> Whichever of these two large series lands first is going to inflict
> fixing this problem on the other.
> 
> As the vdso text is global (to a first approximation), it must not be a
> retpoline if any other process is liable to want to use CET-SS.

Why is that?

> If the retpoline really does need to stay, then the vdso probably needs
> to gain suitable __x86_indirect_thunk_%reg thunks which are patched at
> boot based on the system properties.
> 
> ~Andrew

aka without CET it is patched? With CET, not?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-27 23:37         ` Jarkko Sakkinen
@ 2020-09-28  8:30           ` Borislav Petkov
  2020-09-28 15:02             ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Borislav Petkov @ 2020-09-28  8:30 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Mon, Sep 28, 2020 at 02:37:00AM +0300, Jarkko Sakkinen wrote:
> I did not get Sean's reply, and neither can find it from lore:
> 
> https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#t

Yah, your mail server upgrade broke a lot of stuff. And lore even says
it is not there:

2020-09-25 11:43           ` Jethro Beekman
     [not found]     ` <20200925003808.GB20333@linux.intel.com>		<---
2020-09-25  1:04       ` Jarkko Sakkinen

Lemme bounce it to you.

> I'd make that a description and take away individual parameter
> descriptions. Is that fine?

Sure.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28  0:53                                                 ` Jarkko Sakkinen
@ 2020-09-28 14:04                                                   ` Dave Hansen
  2020-09-28 16:19                                                     ` Jarkko Sakkinen
  2020-10-18  8:49                                                     ` Dr. Greg
  0 siblings, 2 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-28 14:04 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
>> On 9/25/20 12:43 PM, Sean Christopherson wrote:
>>>> That means that the intent argument (SGX_PROT_*) is currently unused.
>>> No, the intent argument is used (eventually) by SGX's ->mprotect()
>>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
>>> subset of the declared/intended protections.
>>>
>>> If ->mprotect() is not merged, then it yes, it will be unused.
>>
>> OK, I think I've got it.
>>
>> I think I'm OK with adding ->mprotect().  As long as folks buy into the
>> argument that intent needs to be checked at mmap() time, they obviously
>> need to be checked at mprotect() too.
>>
>> Jarkko, if you want to try and rewrite the changelog, capturing the
>> discussion here and reply, I think I can ack the resulting patch.  I
>> don't know if that will satisfy the request from Boris from an ack from
>> a "mm person", but we can at least start there. :)
> 
> I think what it needs, based on what I've read, is the step by step
> description of the EMODPE scenarion without this callback and with it.

EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
permissions still specify the most restrictive permissions, which is
what matters the most.

We care about the _worst_ the enclave can do, not what it imposes on
itself on top of that.

> I think other important thing to underline is that an LSM or any other
> security measure can only do a sane decision when the enclave is loaded.
> At that point we know the source (vm_file).

Right, you know the source, but it can be anonymous or a file.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
       [not found]     ` <20200925003808.GB20333@linux.intel.com>
  2020-09-25  1:04       ` Jarkko Sakkinen
  2020-09-25  8:14       ` Borislav Petkov
@ 2020-09-28 14:36       ` Jarkko Sakkinen
  2 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 14:36 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Sep 24, 2020 at 05:38:10PM -0700, Sean Christopherson wrote:
> > I can see why you would write "TCS" though - there's a thread control
> > structure thing too in that patch.
> 
> Argh, it's actually supposed to be TCS, SGX_ENCLAVE_RUN_TSC is the one that's
> wrong.

So I presume that I fixed this one already:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/entry/vdso/vsgx.S

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28  8:30           ` Borislav Petkov
@ 2020-09-28 15:02             ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 15:02 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes, tglx,
	yaozhangx

On Mon, Sep 28, 2020 at 10:30:32AM +0200, Borislav Petkov wrote:
> On Mon, Sep 28, 2020 at 02:37:00AM +0300, Jarkko Sakkinen wrote:
> > I did not get Sean's reply, and neither can find it from lore:
> > 
> > https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#t
> 
> Yah, your mail server upgrade broke a lot of stuff. And lore even says
> it is not there:
> 
> 2020-09-25 11:43           ` Jethro Beekman
>      [not found]     ` <20200925003808.GB20333@linux.intel.com>		<---
> 2020-09-25  1:04       ` Jarkko Sakkinen
> 
> Lemme bounce it to you.

Thank you. I think I have it correctly in my tree. And I actually
noticed that I had the original email stored in wrong archive folder on
my machine (sorry about that), so did I receive it after all, but it
does not exist in lore.

> > I'd make that a description and take away individual parameter
> > descriptions. Is that fine?
> 
> Sure.

/**
 * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
 *					__vdso_sgx_enter_enclave()
 * @run:	Pointer to the caller provided struct sgx_enclave_run
 *
 * The register parameters contain the snapshot of their values at enclave
 * exit
 *
 * Return:
 *  0 or negative to exit vDSO
 *  positive to re-enter enclave (must be EENTER or ERESUME leaf)
 */
typedef int (*sgx_enclave_exit_handler_t)(long rdi, long rsi, long rdx,
					  long rsp, long r8, long r9,
					  struct sgx_enclave_run *run);

I think this looks reasonable now.

Another minor clean up I made is:

struct sgx_enclave_run {
	__u64 tcs;
	__u32 flags;
	__u32 exit_reason;
	__u64 user_handler;
	__u64 user_data;

I.e. got rid of the "user_handler union. Makes the struc less confusing
looking and is consistent with the other structs.

I've been thinking about this tail:

	union {
		struct sgx_enclave_exception exception;

		/* Pad the entire struct to 256 bytes. */
		__u8 pad[256 - 32];
	};
};

I'd just replace this with

	__u64 exception;
};

And do something like (just writing it to the email to show the idea,
have not even compiled this):

-       mov     %eax, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_LEAF)(%rbx)
-       mov     %di,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_TRAPNR)(%rbx)
-       mov     %si,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ERROR_CODE)(%rbx)
-       mov     %rdx, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ADDRESS)(%rbx)
+       mov     SGX_ENCLAVE_RUN_EXCEPTION(%rbx), %rbx
+
+       mov     %eax, (SGX_EX_LEAF)(%rbx)
+       mov     %di,  (SGX_EX_TRAPNR)(%rbx)
+       mov     %si,  (SGX_EX_ERROR_CODE)(%rbx)
+       mov     %rdx, (SGX_EX_ADDRESS)(%rbx)

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-25 18:23   ` Andrew Cooper
  2020-09-28  0:58     ` Jarkko Sakkinen
@ 2020-09-28 15:43     ` Yu, Yu-cheng
  2020-09-28 15:54       ` H.J. Lu
  2020-09-28 20:56       ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: Yu, Yu-cheng @ 2020-09-28 15:43 UTC (permalink / raw)
  To: Andrew Cooper, Jarkko Sakkinen, x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek, bp,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx, H.J. Lu

On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>> new file mode 100644
>> index 000000000000..adbd59d41517
>> --- /dev/null
>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>> @@ -0,0 +1,157 @@
>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
>> <snip>
>> +.Lretpoline:
>> +	call	2f
>> +1:	pause
>> +	lfence
>> +	jmp	1b
>> +2:	mov	%rax, (%rsp)
>> +	ret
> 
> I hate to throw further spanners in the work, but this is not compatible
> with CET, and the user shadow stack work in progress.

Hi Jarkko,

These 1: and 2: targets are reached only from these few lines?  If they 
are direct call/jmp targets, I think it is OK in terms of CET.  If they 
are reached from an instruction like "jmp *%rax", then we need to put in 
an "endbr64".

Yu-cheng

> 
> Whichever of these two large series lands first is going to inflict
> fixing this problem on the other.
> 
> As the vdso text is global (to a first approximation), it must not be a
> retpoline if any other process is liable to want to use CET-SS.
> 
> If the retpoline really does need to stay, then the vdso probably needs
> to gain suitable __x86_indirect_thunk_%reg thunks which are patched at
> boot based on the system properties.
> 
> ~Andrew
> 


^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 15:43     ` Yu, Yu-cheng
@ 2020-09-28 15:54       ` H.J. Lu
  2020-09-28 16:40         ` Yu, Yu-cheng
  2020-09-28 21:36         ` Jarkko Sakkinen
  2020-09-28 20:56       ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: H.J. Lu @ 2020-09-28 15:54 UTC (permalink / raw)
  To: Yu, Yu-cheng
  Cc: Andrew Cooper, Jarkko Sakkinen, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, Andrew Morton, andriy.shevchenko,
	asapek, Borislav Petkov, chenalexchen, conradparker, cyhanish,
	Dave Hansen, Huang, Haitao, josh, kai.huang, kai.svahn, kmoy,
	Christian Ludloff, Andy Lutomirski, nhorman, npmccallum,
	puiterwijk, rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 8:43 AM Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote:
>
> On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> > On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >> new file mode 100644
> >> index 000000000000..adbd59d41517
> >> --- /dev/null
> >> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >> @@ -0,0 +1,157 @@
> >> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> >> <snip>
> >> +.Lretpoline:
> >> +    call    2f
> >> +1:  pause
> >> +    lfence
> >> +    jmp     1b
> >> +2:  mov     %rax, (%rsp)
> >> +    ret
> >
> > I hate to throw further spanners in the work, but this is not compatible
> > with CET, and the user shadow stack work in progress.
>
> Hi Jarkko,
>
> These 1: and 2: targets are reached only from these few lines?  If they
> are direct call/jmp targets, I think it is OK in terms of CET.  If they
> are reached from an instruction like "jmp *%rax", then we need to put in
> an "endbr64".
>

This also isn't compatible with shadow stack.

-- 
H.J.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 14:04                                                   ` Dave Hansen
@ 2020-09-28 16:19                                                     ` Jarkko Sakkinen
  2020-09-28 16:48                                                       ` Dave Hansen
  2020-10-18  8:49                                                     ` Dr. Greg
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 16:19 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> >> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >>>> That means that the intent argument (SGX_PROT_*) is currently unused.
> >>> No, the intent argument is used (eventually) by SGX's ->mprotect()
> >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> >>> subset of the declared/intended protections.
> >>>
> >>> If ->mprotect() is not merged, then it yes, it will be unused.
> >>
> >> OK, I think I've got it.
> >>
> >> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> >> argument that intent needs to be checked at mmap() time, they obviously
> >> need to be checked at mprotect() too.
> >>
> >> Jarkko, if you want to try and rewrite the changelog, capturing the
> >> discussion here and reply, I think I can ack the resulting patch.  I
> >> don't know if that will satisfy the request from Boris from an ack from
> >> a "mm person", but we can at least start there. :)
> > 
> > I think what it needs, based on what I've read, is the step by step
> > description of the EMODPE scenarion without this callback and with it.
> 
> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> permissions still specify the most restrictive permissions, which is
> what matters the most.
> 
> We care about the _worst_ the enclave can do, not what it imposes on
> itself on top of that.

AFAIK it is not, or what we are protecting against with this anyway
then?

Let say an LSM makes decision for the permissions based on origin. If we
do not have this you can:

1. EMODPE
2. mprotect

I.e. whatever LSM decides, won't matter.

The other case, noexec, is now unconditionally denied.

> > I think other important thing to underline is that an LSM or any other
> > security measure can only do a sane decision when the enclave is loaded.
> > At that point we know the source (vm_file).
> 
> Right, you know the source, but it can be anonymous or a file.

They are both origin, the point being that you know what you're dealing
with when you build the enclave, not when you map it.

This is my current rewrite of the commit message in my master branch:

"
    mm: Add 'mprotect' callback to vm_ops
    
    Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
    enclaves, for which page permissions are defined when the enclave is first
    loaded. Once an enclave is loaded and initialized, it can be mapped to the
    process address space.
    
    There is no standard file format for enclaves. They are dynamically built
    and the ways how enclaves are deployed differ greatly. For an app you might
    want to have a simple static binary, but on the other hand for a container
    you might want to dynamically create the whole thing at run-time. Also, the
    existing ecosystem for SGX is already large, which would make the task very
    hard.
    
    Finally, even if there was a standard format, one would still want a
    dynamic way to add pages to the enclave. One big reason for this is that
    enclaves have load time defined pages that represent entry points to the
    enclave. Each entry point can service one hardware thread at a time and
    you might want to run-time parametrize this depending on your environment.
    
    The consequence is that enclaves are best created with an ioctl API and the
    access control can be based only to the origin of the source file for the
    enclave data, i.e. on VMA file pointer and page permissions. For example,
    this could be done with LSM hooks that are triggered in the appropriate
    ioctl's and they could make the access control decision based on this
    information.
    
    Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
    upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
    could upgrade its permissions by using EMODPE followed by an appropriate
    mprotect() call. This would be completely hidden from the kernel.
    
    Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
    that will ensure that {mmap, mprotect}() permissions do not surpass any of
    the original page permissions. This feature allows to maintain and refine
    sane access control for enclaves.
"

I'm mostly happy with this but am open for change suggestions.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 15:54       ` H.J. Lu
@ 2020-09-28 16:40         ` Yu, Yu-cheng
  2020-09-28 21:36         ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Yu, Yu-cheng @ 2020-09-28 16:40 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Andrew Cooper, Jarkko Sakkinen, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, Andrew Morton, andriy.shevchenko,
	asapek, Borislav Petkov, chenalexchen, conradparker, cyhanish,
	Dave Hansen, Huang, Haitao, josh, kai.huang, kai.svahn, kmoy,
	Christian Ludloff, Andy Lutomirski, nhorman, npmccallum,
	puiterwijk, rientjes, Thomas Gleixner, yaozhangx

On 9/28/2020 8:54 AM, H.J. Lu wrote:
> On Mon, Sep 28, 2020 at 8:43 AM Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote:
>>
>> On 9/25/2020 11:23 AM, Andrew Cooper wrote:
>>> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
>>>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>>> new file mode 100644
>>>> index 000000000000..adbd59d41517
>>>> --- /dev/null
>>>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>>> @@ -0,0 +1,157 @@
>>>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
>>>> <snip>
>>>> +.Lretpoline:
>>>> +    call    2f
>>>> +1:  pause
>>>> +    lfence
>>>> +    jmp     1b
>>>> +2:  mov     %rax, (%rsp)
>>>> +    ret
>>>
>>> I hate to throw further spanners in the work, but this is not compatible
>>> with CET, and the user shadow stack work in progress.
>>
>> Hi Jarkko,
>>
>> These 1: and 2: targets are reached only from these few lines?  If they
>> are direct call/jmp targets, I think it is OK in terms of CET.  If they
>> are reached from an instruction like "jmp *%rax", then we need to put in
>> an "endbr64".
>>
> 
> This also isn't compatible with shadow stack.
> 

Then, when shadow stack is enabled, disable this?

Yu-cheng

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28  0:58     ` Jarkko Sakkinen
@ 2020-09-28 16:44       ` Andrew Cooper
  2020-09-28 18:07         ` H.J. Lu
  2020-09-28 20:42         ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Andrew Cooper @ 2020-09-28 16:44 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu, Yu-cheng Yu, Andrew Cooper

On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
>> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
>>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>> new file mode 100644
>>> index 000000000000..adbd59d41517
>>> --- /dev/null
>>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>> @@ -0,0 +1,157 @@
>>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
>>> <snip>
>>> +.Lretpoline:
>>> +	call	2f
>>> +1:	pause
>>> +	lfence
>>> +	jmp	1b
>>> +2:	mov	%rax, (%rsp)
>>> +	ret
>> I hate to throw further spanners in the work, but this is not compatible
>> with CET, and the user shadow stack work in progress.
> CET goes beyond my expertise. Can you describe, at least rudimentary,
> how this code is not compatible?

CET Shadow Stacks detect attacks which modify the return address on the
stack.

Retpoline *is* a ROP gadget.  It really does modify the return address
on the stack, even if its purpose is defensive (vs Spectre v2) rather
than malicious.

>> Whichever of these two large series lands first is going to inflict
>> fixing this problem on the other.
>>
>> As the vdso text is global (to a first approximation), it must not be a
>> retpoline if any other process is liable to want to use CET-SS.
> Why is that?

Because when CET-SS is enabled, the ret will suffer a #CP exception
(return address on the stack not matching the one recorded in the shadow
stack), which I presume/hope is wired into SIGSEGV.

~Andrew

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 16:19                                                     ` Jarkko Sakkinen
@ 2020-09-28 16:48                                                       ` Dave Hansen
  2020-09-28 19:32                                                         ` Jarkko Sakkinen
  2020-09-28 20:18                                                         ` Jarkko Sakkinen
  0 siblings, 2 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-28 16:48 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
>> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
>> permissions still specify the most restrictive permissions, which is
>> what matters the most.
>>
>> We care about the _worst_ the enclave can do, not what it imposes on
>> itself on top of that.
> 
> AFAIK it is not, or what we are protecting against with this anyway
> then?
> 
> Let say an LSM makes decision for the permissions based on origin. If we
> do not have this you can:
> 
> 1. EMODPE
> 2. mprotect

The thing that matters is that the enclave needs relaxed permissions
from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
permissions is entirely irrelevant to the kernel.

> I.e. whatever LSM decides, won't matter.
> 
> The other case, noexec, is now unconditionally denied.



>>> I think other important thing to underline is that an LSM or any other
>>> security measure can only do a sane decision when the enclave is loaded.
>>> At that point we know the source (vm_file).
>>
>> Right, you know the source, but it can be anonymous or a file.
> 
> They are both origin, the point being that you know what you're dealing
> with when you build the enclave, not when you map it.
> 
> This is my current rewrite of the commit message in my master branch:
> 
> "
>     mm: Add 'mprotect' callback to vm_ops
>     
>     Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
>     enclaves, for which page permissions are defined when the enclave is first
>     loaded. Once an enclave is loaded and initialized, it can be mapped to the
>     process address space.
>     
>     There is no standard file format for enclaves. They are dynamically built
>     and the ways how enclaves are deployed differ greatly. For an app you might
>     want to have a simple static binary, but on the other hand for a container
>     you might want to dynamically create the whole thing at run-time. Also, the
>     existing ecosystem for SGX is already large, which would make the task very
>     hard.

I'm sorry I ever mentioned the file format.  Please remove any mention
of it.  It's irrelevant.  This entire paragraph is irrelevant.

>     Finally, even if there was a standard format, one would still want a
>     dynamic way to add pages to the enclave. One big reason for this is that
>     enclaves have load time defined pages that represent entry points to the
>     enclave. Each entry point can service one hardware thread at a time and
>     you might want to run-time parametrize this depending on your environment.

I also don't know what this paragraph has to do with the mprotect()
hook.  Please remove it.

>     The consequence is that enclaves are best created with an ioctl API and the
>     access control can be based only to the origin of the source file for the
>     enclave data, i.e. on VMA file pointer and page permissions. For example,

It's not strictly page permissions, though.  It's actually VMA
permissions.  The thing you copy from might be the zero page, and even
though it has Write=0 page permissions, apps are completely OK to write
to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.

It's also not just about *files*.  Anonymous memory might or might not
be a valid source for enclave data based on LSM hooks.

>     this could be done with LSM hooks that are triggered in the appropriate
>     ioctl's and they could make the access control decision based on this
>     information.

This "appropriate ioctl's" is not good changelog material.  Please use
those bytes to convey actual information.

	... this could be done with LSM hooks which restrict the source
	of enclave page data

I don't care that it's an ioctl(), really.  What matters is what the
ioctl() does: copy data into enclave pages.

>     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
>     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
>     could upgrade its permissions by using EMODPE followed by an appropriate
>     mprotect() call. This would be completely hidden from the kernel.

There's too much irrelevant info.

I'll say it again: all that matters is that enclaves can legitimately,
safely, and securely have a need for the kernel to change page
permissions.  That's *IT*.  EMODPE just happens to be part of the
mechanism that makes these permission changes safe for enclaves.  It's a
side show.

>     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
>     that will ensure that {mmap, mprotect}() permissions do not surpass any of
>     the original page permissions. This feature allows to maintain and refine
>     sane access control for enclaves.

Instead of "original", I'd stick to the "source" page nomenclature.
There are also "original" permissions with mprotect().

Also, it's literally OK for the enclave page permissions to surpass the
original (source) page permissions.  That sentence is incorrect, or at
least misleadingly imprecise.

> I'm mostly happy with this but am open for change suggestions.

I wrote a pretty nice description of this.  It was about 90% correct,
shorter, and conveyed more information.  I'd suggest starting with that.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 16:44       ` Andrew Cooper
@ 2020-09-28 18:07         ` H.J. Lu
  2020-09-28 18:12           ` Andy Lutomirski
  2020-09-28 21:41           ` Jarkko Sakkinen
  2020-09-28 20:42         ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: H.J. Lu @ 2020-09-28 18:07 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Jarkko Sakkinen, the arch/x86 maintainers, linux-sgx, LKML,
	Sean Christopherson, Andy Lutomirski, Jethro Beekman,
	Cedric Xing, Andrew Morton, andriy.shevchenko, asapek,
	Borislav Petkov, chenalexchen, conradparker, cyhanish,
	Dave Hansen, Huang, Haitao, josh, kai.huang, kai.svahn, kmoy,
	Christian Ludloff, Andy Lutomirski, nhorman, npmccallum,
	puiterwijk, rientjes, Thomas Gleixner, yaozhangx, Yu-cheng Yu

On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>> new file mode 100644
> >>> index 000000000000..adbd59d41517
> >>> --- /dev/null
> >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>> @@ -0,0 +1,157 @@
> >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> >>> <snip>
> >>> +.Lretpoline:
> >>> +   call    2f
> >>> +1: pause
> >>> +   lfence
> >>> +   jmp     1b
> >>> +2: mov     %rax, (%rsp)
> >>> +   ret
> >> I hate to throw further spanners in the work, but this is not compatible
> >> with CET, and the user shadow stack work in progress.
> > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > how this code is not compatible?
>
> CET Shadow Stacks detect attacks which modify the return address on the
> stack.
>
> Retpoline *is* a ROP gadget.  It really does modify the return address
> on the stack, even if its purpose is defensive (vs Spectre v2) rather
> than malicious.
>
> >> Whichever of these two large series lands first is going to inflict
> >> fixing this problem on the other.
> >>
> >> As the vdso text is global (to a first approximation), it must not be a
> >> retpoline if any other process is liable to want to use CET-SS.
> > Why is that?
>
> Because when CET-SS is enabled, the ret will suffer a #CP exception
> (return address on the stack not matching the one recorded in the shadow
> stack), which I presume/hope is wired into SIGSEGV.
>

Here is the CET compatible retpoline:

endbr64
/* Check if shadow stack is in use.  NB: R11 is the only usable
   scratch register for function calls.  */
xorl %r11d, %r11d
rdsspq %r11
testq %r11, %r11
jnz 3f
call 2f
1:
pause
lfence
jmp 1b
2:
mov %rax, (%rsp)
ret
3:
/* Shadow stack is in use.  Make the indirect call.  */
call *%rax
ret


-- 
H.J.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 18:07         ` H.J. Lu
@ 2020-09-28 18:12           ` Andy Lutomirski
  2020-09-28 18:17             ` Dave Hansen
  2020-09-28 21:56             ` Jarkko Sakkinen
  2020-09-28 21:41           ` Jarkko Sakkinen
  1 sibling, 2 replies; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-28 18:12 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Andrew Cooper, Jarkko Sakkinen, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Jethro Beekman,
	Cedric Xing, Andrew Morton, Andy Shevchenko, asapek,
	Borislav Petkov, chenalexchen, Conrad Parker, cyhanish,
	Dave Hansen, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn,
	Kai, Keith Moyer, Christian Ludloff, Andy Lutomirski,
	Neil Horman, Nathaniel McCallum, Patrick Uiterwijk,
	David Rientjes, Thomas Gleixner, yaozhangx, Yu-cheng Yu

On Mon, Sep 28, 2020 at 11:08 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> > >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >>> new file mode 100644
> > >>> index 000000000000..adbd59d41517
> > >>> --- /dev/null
> > >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >>> @@ -0,0 +1,157 @@
> > >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > >>> <snip>
> > >>> +.Lretpoline:
> > >>> +   call    2f
> > >>> +1: pause
> > >>> +   lfence
> > >>> +   jmp     1b
> > >>> +2: mov     %rax, (%rsp)
> > >>> +   ret
> > >> I hate to throw further spanners in the work, but this is not compatible
> > >> with CET, and the user shadow stack work in progress.
> > > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > > how this code is not compatible?
> >
> > CET Shadow Stacks detect attacks which modify the return address on the
> > stack.
> >
> > Retpoline *is* a ROP gadget.  It really does modify the return address
> > on the stack, even if its purpose is defensive (vs Spectre v2) rather
> > than malicious.
> >
> > >> Whichever of these two large series lands first is going to inflict
> > >> fixing this problem on the other.
> > >>
> > >> As the vdso text is global (to a first approximation), it must not be a
> > >> retpoline if any other process is liable to want to use CET-SS.
> > > Why is that?
> >
> > Because when CET-SS is enabled, the ret will suffer a #CP exception
> > (return address on the stack not matching the one recorded in the shadow
> > stack), which I presume/hope is wired into SIGSEGV.
> >
>
> Here is the CET compatible retpoline:
>
> endbr64
> /* Check if shadow stack is in use.  NB: R11 is the only usable
>    scratch register for function calls.  */
> xorl %r11d, %r11d
> rdsspq %r11
> testq %r11, %r11
> jnz 3f
> call 2f
> 1:
> pause
> lfence
> jmp 1b
> 2:
> mov %rax, (%rsp)
> ret
> 3:
> /* Shadow stack is in use.  Make the indirect call.  */
> call *%rax
> ret

What do we expect user programs to do on CET systems?  It would be
nice if we could instead ALTERNATIVE this out if X86_FEATURE_SHSTK.

--Andy

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 18:12           ` Andy Lutomirski
@ 2020-09-28 18:17             ` Dave Hansen
  2020-09-28 22:07               ` Jarkko Sakkinen
  2020-09-28 21:56             ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-28 18:17 UTC (permalink / raw)
  To: Andy Lutomirski, H.J. Lu
  Cc: Andrew Cooper, Jarkko Sakkinen, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Jethro Beekman,
	Cedric Xing, Andrew Morton, Andy Shevchenko, asapek,
	Borislav Petkov, chenalexchen, Conrad Parker, cyhanish, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On 9/28/20 11:12 AM, Andy Lutomirski wrote:
>> endbr64
>> /* Check if shadow stack is in use.  NB: R11 is the only usable
>>    scratch register for function calls.  */
>> xorl %r11d, %r11d
>> rdsspq %r11
>> testq %r11, %r11
>> jnz 3f
>> call 2f
>> 1:
>> pause
>> lfence
>> jmp 1b
>> 2:
>> mov %rax, (%rsp)
>> ret
>> 3:
>> /* Shadow stack is in use.  Make the indirect call.  */
>> call *%rax
>> ret
> What do we expect user programs to do on CET systems?  It would be
> nice if we could instead ALTERNATIVE this out if X86_FEATURE_SHSTK.

Shouldn't we just be able to use X86_FEATURE_RETPOLINE?

We probably need a mechanism to force X86_FEATURE_SHSTK and
X86_FEATURE_RETPOLINE to be mutually exclusive if we don't have one already.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 16:48                                                       ` Dave Hansen
@ 2020-09-28 19:32                                                         ` Jarkko Sakkinen
  2020-09-28 19:45                                                           ` Dave Hansen
  2020-09-28 20:18                                                         ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 19:32 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> >> permissions still specify the most restrictive permissions, which is
> >> what matters the most.
> >>
> >> We care about the _worst_ the enclave can do, not what it imposes on
> >> itself on top of that.
> > 
> > AFAIK it is not, or what we are protecting against with this anyway
> > then?
> > 
> > Let say an LSM makes decision for the permissions based on origin. If we
> > do not have this you can:
> > 
> > 1. EMODPE
> > 2. mprotect
> 
> The thing that matters is that the enclave needs relaxed permissions
> from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
> permissions is entirely irrelevant to the kernel.

Lets try to find the root of misunderstanding, shall we?

I'm assuming that your statement is encapsulated to:

https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/

I do agree with this.

And here is a direct quote:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or the enclave itself are consistent with the earlier
declared permissions."

Without the mprotect callback in place, by using EMODPE and mprotect,
one could surpass the permisssions that we declared earlier.

With the callback in place this is not possible. EMODPE can be freely
used but mprotect() always caps the permissions. It enables us to *not
care* about EMODPE.

My problem is that I fully agree what you say in your description but
disagree on that EMODPE should not be mentioned.

> >     There is no standard file format for enclaves. They are dynamically built
> >     and the ways how enclaves are deployed differ greatly. For an app you might
> >     want to have a simple static binary, but on the other hand for a container
> >     you might want to dynamically create the whole thing at run-time. Also, the
> >     existing ecosystem for SGX is already large, which would make the task very
> >     hard.
> 
> I'm sorry I ever mentioned the file format.  Please remove any mention
> of it.  It's irrelevant.  This entire paragraph is irrelevant.

Not sure if it is or not. It is merely to state that execve() path is
possible. Perhaps should be toned down in some way. Should be like the
a small remark at most.

> >     Finally, even if there was a standard format, one would still want a
> >     dynamic way to add pages to the enclave. One big reason for this is that
> >     enclaves have load time defined pages that represent entry points to the
> >     enclave. Each entry point can service one hardware thread at a time and
> >     you might want to run-time parametrize this depending on your environment.
> 
> I also don't know what this paragraph has to do with the mprotect()
> hook.  Please remove it.

Agreed.

> >     The consequence is that enclaves are best created with an ioctl API and the
> >     access control can be based only to the origin of the source file for the
> >     enclave data, i.e. on VMA file pointer and page permissions. For example,
> 
> It's not strictly page permissions, though.  It's actually VMA
> permissions.  The thing you copy from might be the zero page, and even
> though it has Write=0 page permissions, apps are completely OK to write
> to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.
> 
> It's also not just about *files*.  Anonymous memory might or might not
> be a valid source for enclave data based on LSM hooks.

Yes, this should be refined, agreed. Source can be either anonymous page
or a file, I do of course understand that.

> >     this could be done with LSM hooks that are triggered in the appropriate
> >     ioctl's and they could make the access control decision based on this
> >     information.
> 
> This "appropriate ioctl's" is not good changelog material.  Please use
> those bytes to convey actual information.
> 
> 	... this could be done with LSM hooks which restrict the source
> 	of enclave page data
> 
> I don't care that it's an ioctl(), really.  What matters is what the
> ioctl() does: copy data into enclave pages.

Agreed.

> >     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> >     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> >     could upgrade its permissions by using EMODPE followed by an appropriate
> >     mprotect() call. This would be completely hidden from the kernel.
> 
> There's too much irrelevant info.
> 
> I'll say it again: all that matters is that enclaves can legitimately,
> safely, and securely have a need for the kernel to change page
> permissions.  That's *IT*.  EMODPE just happens to be part of the
> mechanism that makes these permission changes safe for enclaves.  It's a
> side show.

Disagree on this. I wrote my statement about. Maybe it should not be
driving argument but should be definitely part of the description.

> >     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> >     that will ensure that {mmap, mprotect}() permissions do not surpass any of
> >     the original page permissions. This feature allows to maintain and refine
> >     sane access control for enclaves.
> 
> Instead of "original", I'd stick to the "source" page nomenclature.
> There are also "original" permissions with mprotect().
> 
> Also, it's literally OK for the enclave page permissions to surpass the
> original (source) page permissions.  That sentence is incorrect, or at
> least misleadingly imprecise.

Yes it is. It's fine to use EMODPE to upgrade the perms, and by having
this hook, doing anything nasty with it is impossible.

> > I'm mostly happy with this but am open for change suggestions.
> 
> I wrote a pretty nice description of this.  It was about 90% correct,
> shorter, and conveyed more information.  I'd suggest starting with that.

I should have added a disclaimer that my description is not up to date.
Just do not want to make anything final before this EMODPE discussion
has some conclusion.

I'm fine using your description as basis for the commit message if as long
as these few details are settled.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 19:32                                                         ` Jarkko Sakkinen
@ 2020-09-28 19:45                                                           ` Dave Hansen
  2020-09-28 20:19                                                             ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-28 19:45 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
> My problem is that I fully agree what you say in your description but
> disagree on that EMODPE should not be mentioned.

I'll just be very clear: I'm not willing to ack any patch with a
changelog that has more than a passing mention of EMODPE.

Do what you think is best, but if sticking to your guns may deplete the
pool of folks willing to ack your patch.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 16:48                                                       ` Dave Hansen
  2020-09-28 19:32                                                         ` Jarkko Sakkinen
@ 2020-09-28 20:18                                                         ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 20:18 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> >> permissions still specify the most restrictive permissions, which is
> >> what matters the most.
> >>
> >> We care about the _worst_ the enclave can do, not what it imposes on
> >> itself on top of that.
> > 
> > AFAIK it is not, or what we are protecting against with this anyway
> > then?
> > 
> > Let say an LSM makes decision for the permissions based on origin. If we
> > do not have this you can:
> > 
> > 1. EMODPE
> > 2. mprotect
> 
> The thing that matters is that the enclave needs relaxed permissions
> from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
> permissions is entirely irrelevant to the kernel.

Lets try to find the root of misunderstanding, shall we?

I'm assuming that your statement is encapsulated to:

https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/

I do agree with this.

And here is a direct quote:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or the enclave itself are consistent with the earlier
declared permissions."

Without the mprotect callback in place, by using EMODPE and mprotect,
one could surpass the permisssions that we declared earlier.

With the callback in place this is not possible. EMODPE can be freely
used but mprotect() always caps the permissions. It enables us to *not
care* about EMODPE.

My problem is that I fully agree what you say in your description but
disagree on that EMODPE should not be mentioned.

> >     There is no standard file format for enclaves. They are dynamically built
> >     and the ways how enclaves are deployed differ greatly. For an app you might
> >     want to have a simple static binary, but on the other hand for a container
> >     you might want to dynamically create the whole thing at run-time. Also, the
> >     existing ecosystem for SGX is already large, which would make the task very
> >     hard.
> 
> I'm sorry I ever mentioned the file format.  Please remove any mention
> of it.  It's irrelevant.  This entire paragraph is irrelevant.

Not sure if it is or not. It is merely to state that execve() path is
possible. Perhaps should be toned down in some way. Should be like the
a small remark at most.

> >     Finally, even if there was a standard format, one would still want a
> >     dynamic way to add pages to the enclave. One big reason for this is that
> >     enclaves have load time defined pages that represent entry points to the
> >     enclave. Each entry point can service one hardware thread at a time and
> >     you might want to run-time parametrize this depending on your environment.
> 
> I also don't know what this paragraph has to do with the mprotect()
> hook.  Please remove it.

Agreed.

> >     The consequence is that enclaves are best created with an ioctl API and the
> >     access control can be based only to the origin of the source file for the
> >     enclave data, i.e. on VMA file pointer and page permissions. For example,
> 
> It's not strictly page permissions, though.  It's actually VMA
> permissions.  The thing you copy from might be the zero page, and even
> though it has Write=0 page permissions, apps are completely OK to write
> to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.
> 
> It's also not just about *files*.  Anonymous memory might or might not
> be a valid source for enclave data based on LSM hooks.

Yes, this should be refined, agreed. Source can be either anonymous page
or a file, I do of course understand that.

> >     this could be done with LSM hooks that are triggered in the appropriate
> >     ioctl's and they could make the access control decision based on this
> >     information.
> 
> This "appropriate ioctl's" is not good changelog material.  Please use
> those bytes to convey actual information.
> 
> 	... this could be done with LSM hooks which restrict the source
> 	of enclave page data
> 
> I don't care that it's an ioctl(), really.  What matters is what the
> ioctl() does: copy data into enclave pages.

Agreed.

> >     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> >     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> >     could upgrade its permissions by using EMODPE followed by an appropriate
> >     mprotect() call. This would be completely hidden from the kernel.
> 
> There's too much irrelevant info.
> 
> I'll say it again: all that matters is that enclaves can legitimately,
> safely, and securely have a need for the kernel to change page
> permissions.  That's *IT*.  EMODPE just happens to be part of the
> mechanism that makes these permission changes safe for enclaves.  It's a
> side show.

Disagree on this. I wrote my statement about. Maybe it should not be
driving argument but should be definitely part of the description.

> >     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> >     that will ensure that {mmap, mprotect}() permissions do not surpass any of
> >     the original page permissions. This feature allows to maintain and refine
> >     sane access control for enclaves.
> 
> Instead of "original", I'd stick to the "source" page nomenclature.
> There are also "original" permissions with mprotect().
> 
> Also, it's literally OK for the enclave page permissions to surpass the
> original (source) page permissions.  That sentence is incorrect, or at
> least misleadingly imprecise.

Yes it is. It's fine to use EMODPE to upgrade the perms, and by having
this hook, doing anything nasty with it is impossible.

> > I'm mostly happy with this but am open for change suggestions.
> 
> I wrote a pretty nice description of this.  It was about 90% correct,
> shorter, and conveyed more information.  I'd suggest starting with that.

I should have added a disclaimer that my description is not up to date.
Just do not want to make anything final before this EMODPE discussion
has some conclusion.

I'm fine using your description as basis for the commit message if as long
as these few details are settled.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 19:45                                                           ` Dave Hansen
@ 2020-09-28 20:19                                                             ` Jarkko Sakkinen
  2020-09-29  1:37                                                               ` Andy Lutomirski
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 20:19 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
> > My problem is that I fully agree what you say in your description but
> > disagree on that EMODPE should not be mentioned.
> 
> I'll just be very clear: I'm not willing to ack any patch with a
> changelog that has more than a passing mention of EMODPE.
> 
> Do what you think is best, but if sticking to your guns may deplete the
> pool of folks willing to ack your patch.

I do see it mentioned in other responses too in this thread, and not
just mine.

And here is even a request to get it to the changelog:

https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/

I'm absolutely fine not to mention EMODPE but after re-reading the
thread, it is not like there is one voice on it. I don't really
care all that much whether it is mentioned or not but there should
be some reasonable logic behind the decision.

PS. I just noticed that my previous response did not reach lore so
I bounced it again.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 16:44       ` Andrew Cooper
  2020-09-28 18:07         ` H.J. Lu
@ 2020-09-28 20:42         ` Jarkko Sakkinen
  2020-09-28 23:52           ` Andrew Cooper
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 20:42 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu, Yu-cheng Yu

On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>> new file mode 100644
> >>> index 000000000000..adbd59d41517
> >>> --- /dev/null
> >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>> @@ -0,0 +1,157 @@
> >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> >>> <snip>
> >>> +.Lretpoline:
> >>> +	call	2f
> >>> +1:	pause
> >>> +	lfence
> >>> +	jmp	1b
> >>> +2:	mov	%rax, (%rsp)
> >>> +	ret
> >> I hate to throw further spanners in the work, but this is not compatible
> >> with CET, and the user shadow stack work in progress.
> > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > how this code is not compatible?
> 
> CET Shadow Stacks detect attacks which modify the return address on the
> stack.
> 
> Retpoline *is* a ROP gadget.  It really does modify the return address
> on the stack, even if its purpose is defensive (vs Spectre v2) rather
> than malicious.

Aah. I get that, yes.

Kernel is full of retpoline but I presume that ring-0 does not use CET.

The situation with callback is follows: for a run-time the user_handler
by all practical means is always the same. There is ever only one user
handler that gets executed. I.e. the indirect callback will always lead
to the same thing. I wonder how much assets an adversary would get if
we just remove retpoline bits (not much thinking done yet on that).

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 15:43     ` Yu, Yu-cheng
  2020-09-28 15:54       ` H.J. Lu
@ 2020-09-28 20:56       ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 20:56 UTC (permalink / raw)
  To: Yu, Yu-cheng
  Cc: Andrew Cooper, x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu

On Mon, Sep 28, 2020 at 08:43:16AM -0700, Yu, Yu-cheng wrote:
> On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> > On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > new file mode 100644
> > > index 000000000000..adbd59d41517
> > > --- /dev/null
> > > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > @@ -0,0 +1,157 @@
> > > +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > > <snip>
> > > +.Lretpoline:
> > > +	call	2f
> > > +1:	pause
> > > +	lfence
> > > +	jmp	1b
> > > +2:	mov	%rax, (%rsp)
> > > +	ret
> > 
> > I hate to throw further spanners in the work, but this is not compatible
> > with CET, and the user shadow stack work in progress.
> 
> Hi Jarkko,
> 
> These 1: and 2: targets are reached only from these few lines?  If they are
> direct call/jmp targets, I think it is OK in terms of CET.  If they are
> reached from an instruction like "jmp *%rax", then we need to put in an
> "endbr64".
> 
> Yu-cheng

The invocation is over here:

	/* Load the callback pointer to %rax and invoke it via retpoline. */
	mov	SGX_ENCLAVE_RUN_USER_HANDLER(%rax), %rax
	call	.Lretpoline

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 15:54       ` H.J. Lu
  2020-09-28 16:40         ` Yu, Yu-cheng
@ 2020-09-28 21:36         ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 21:36 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Yu, Yu-cheng, Andrew Cooper, the arch/x86 maintainers, linux-sgx,
	LKML, Sean Christopherson, Andy Lutomirski, Jethro Beekman,
	Cedric Xing, Andrew Morton, andriy.shevchenko, asapek,
	Borislav Petkov, chenalexchen, conradparker, cyhanish,
	Dave Hansen, Huang, Haitao, josh, kai.huang, kai.svahn, kmoy,
	Christian Ludloff, Andy Lutomirski, nhorman, npmccallum,
	puiterwijk, rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 08:54:01AM -0700, H.J. Lu wrote:
> On Mon, Sep 28, 2020 at 8:43 AM Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote:
> >
> > On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> > > On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > >> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >> new file mode 100644
> > >> index 000000000000..adbd59d41517
> > >> --- /dev/null
> > >> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >> @@ -0,0 +1,157 @@
> > >> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > >> <snip>
> > >> +.Lretpoline:
> > >> +    call    2f
> > >> +1:  pause
> > >> +    lfence
> > >> +    jmp     1b
> > >> +2:  mov     %rax, (%rsp)
> > >> +    ret
> > >
> > > I hate to throw further spanners in the work, but this is not compatible
> > > with CET, and the user shadow stack work in progress.
> >
> > Hi Jarkko,
> >
> > These 1: and 2: targets are reached only from these few lines?  If they
> > are direct call/jmp targets, I think it is OK in terms of CET.  If they
> > are reached from an instruction like "jmp *%rax", then we need to put in
> > an "endbr64".
> >
> 
> This also isn't compatible with shadow stack.
> 
> -- 
> H.J.

I have the now full picture of the problem thanks to Andrew's response
[1]. And Dave Hansen just explained me in detail the context and
background with [2]. So I'd guess this will get sorted out soon.

If you don't mind I'll CC you to this commit when I send the next
version?

[1] https://lkml.org/lkml/2020/9/28/1153
[2] https://lkml.org/lkml/2020/9/25/1122

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 18:07         ` H.J. Lu
  2020-09-28 18:12           ` Andy Lutomirski
@ 2020-09-28 21:41           ` Jarkko Sakkinen
  1 sibling, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 21:41 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Andrew Cooper, the arch/x86 maintainers, linux-sgx, LKML,
	Sean Christopherson, Andy Lutomirski, Jethro Beekman,
	Cedric Xing, Andrew Morton, andriy.shevchenko, asapek,
	Borislav Petkov, chenalexchen, conradparker, cyhanish,
	Dave Hansen, Huang, Haitao, josh, kai.huang, kai.svahn, kmoy,
	Christian Ludloff, Andy Lutomirski, nhorman, npmccallum,
	puiterwijk, rientjes, Thomas Gleixner, yaozhangx, Yu-cheng Yu

On Mon, Sep 28, 2020 at 11:07:47AM -0700, H.J. Lu wrote:
> On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> > >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >>> new file mode 100644
> > >>> index 000000000000..adbd59d41517
> > >>> --- /dev/null
> > >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > >>> @@ -0,0 +1,157 @@
> > >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > >>> <snip>
> > >>> +.Lretpoline:
> > >>> +   call    2f
> > >>> +1: pause
> > >>> +   lfence
> > >>> +   jmp     1b
> > >>> +2: mov     %rax, (%rsp)
> > >>> +   ret
> > >> I hate to throw further spanners in the work, but this is not compatible
> > >> with CET, and the user shadow stack work in progress.
> > > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > > how this code is not compatible?
> >
> > CET Shadow Stacks detect attacks which modify the return address on the
> > stack.
> >
> > Retpoline *is* a ROP gadget.  It really does modify the return address
> > on the stack, even if its purpose is defensive (vs Spectre v2) rather
> > than malicious.
> >
> > >> Whichever of these two large series lands first is going to inflict
> > >> fixing this problem on the other.
> > >>
> > >> As the vdso text is global (to a first approximation), it must not be a
> > >> retpoline if any other process is liable to want to use CET-SS.
> > > Why is that?
> >
> > Because when CET-SS is enabled, the ret will suffer a #CP exception
> > (return address on the stack not matching the one recorded in the shadow
> > stack), which I presume/hope is wired into SIGSEGV.
> >
> 
> Here is the CET compatible retpoline:
> 
> endbr64
> /* Check if shadow stack is in use.  NB: R11 is the only usable
>    scratch register for function calls.  */
> xorl %r11d, %r11d
> rdsspq %r11
> testq %r11, %r11
> jnz 3f
> call 2f
> 1:
> pause
> lfence
> jmp 1b
> 2:
> mov %rax, (%rsp)
> ret
> 3:
> /* Shadow stack is in use.  Make the indirect call.  */
> call *%rax
> ret

Right, so I have actually two alternatives: this and boot time patching:

https://lkml.org/lkml/2020/9/25/1122

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 18:12           ` Andy Lutomirski
  2020-09-28 18:17             ` Dave Hansen
@ 2020-09-28 21:56             ` Jarkko Sakkinen
  2020-09-28 22:06               ` H.J. Lu
  1 sibling, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 21:56 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: H.J. Lu, Andrew Cooper, the arch/x86 maintainers, linux-sgx,
	LKML, Sean Christopherson, Jethro Beekman, Cedric Xing,
	Andrew Morton, Andy Shevchenko, asapek, Borislav Petkov,
	chenalexchen, Conrad Parker, cyhanish, Dave Hansen, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On Mon, Sep 28, 2020 at 11:12:08AM -0700, Andy Lutomirski wrote:
> On Mon, Sep 28, 2020 at 11:08 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > >
> > > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> > > >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > > >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > >>> new file mode 100644
> > > >>> index 000000000000..adbd59d41517
> > > >>> --- /dev/null
> > > >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > >>> @@ -0,0 +1,157 @@
> > > >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > > >>> <snip>
> > > >>> +.Lretpoline:
> > > >>> +   call    2f
> > > >>> +1: pause
> > > >>> +   lfence
> > > >>> +   jmp     1b
> > > >>> +2: mov     %rax, (%rsp)
> > > >>> +   ret
> > > >> I hate to throw further spanners in the work, but this is not compatible
> > > >> with CET, and the user shadow stack work in progress.
> > > > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > > > how this code is not compatible?
> > >
> > > CET Shadow Stacks detect attacks which modify the return address on the
> > > stack.
> > >
> > > Retpoline *is* a ROP gadget.  It really does modify the return address
> > > on the stack, even if its purpose is defensive (vs Spectre v2) rather
> > > than malicious.
> > >
> > > >> Whichever of these two large series lands first is going to inflict
> > > >> fixing this problem on the other.
> > > >>
> > > >> As the vdso text is global (to a first approximation), it must not be a
> > > >> retpoline if any other process is liable to want to use CET-SS.
> > > > Why is that?
> > >
> > > Because when CET-SS is enabled, the ret will suffer a #CP exception
> > > (return address on the stack not matching the one recorded in the shadow
> > > stack), which I presume/hope is wired into SIGSEGV.
> > >
> >
> > Here is the CET compatible retpoline:
> >
> > endbr64
> > /* Check if shadow stack is in use.  NB: R11 is the only usable
> >    scratch register for function calls.  */
> > xorl %r11d, %r11d
> > rdsspq %r11
> > testq %r11, %r11
> > jnz 3f
> > call 2f
> > 1:
> > pause
> > lfence
> > jmp 1b
> > 2:
> > mov %rax, (%rsp)
> > ret
> > 3:
> > /* Shadow stack is in use.  Make the indirect call.  */
> > call *%rax
> > ret
> 
> What do we expect user programs to do on CET systems?  It would be
> nice if we could instead ALTERNATIVE this out if X86_FEATURE_SHSTK.
> 
> --Andy

I'm open to do either solution. My thinking was to initially do things
vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
on details how that thing works and it should be perfectly usable for
our use case.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 21:56             ` Jarkko Sakkinen
@ 2020-09-28 22:06               ` H.J. Lu
  2020-09-28 22:18                 ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: H.J. Lu @ 2020-09-28 22:06 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Andy Lutomirski, Andrew Cooper, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Jethro Beekman,
	Cedric Xing, Andrew Morton, Andy Shevchenko, asapek,
	Borislav Petkov, chenalexchen, Conrad Parker, cyhanish,
	Dave Hansen, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn,
	Kai, Keith Moyer, Christian Ludloff, Neil Horman,
	Nathaniel McCallum, Patrick Uiterwijk, David Rientjes,
	Thomas Gleixner, yaozhangx, Yu-cheng Yu

On Mon, Sep 28, 2020 at 2:56 PM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Mon, Sep 28, 2020 at 11:12:08AM -0700, Andy Lutomirski wrote:
> > On Mon, Sep 28, 2020 at 11:08 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > >
> > > > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > > > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> > > > >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > > > >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > > >>> new file mode 100644
> > > > >>> index 000000000000..adbd59d41517
> > > > >>> --- /dev/null
> > > > >>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > > >>> @@ -0,0 +1,157 @@
> > > > >>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > > > >>> <snip>
> > > > >>> +.Lretpoline:
> > > > >>> +   call    2f
> > > > >>> +1: pause
> > > > >>> +   lfence
> > > > >>> +   jmp     1b
> > > > >>> +2: mov     %rax, (%rsp)
> > > > >>> +   ret
> > > > >> I hate to throw further spanners in the work, but this is not compatible
> > > > >> with CET, and the user shadow stack work in progress.
> > > > > CET goes beyond my expertise. Can you describe, at least rudimentary,
> > > > > how this code is not compatible?
> > > >
> > > > CET Shadow Stacks detect attacks which modify the return address on the
> > > > stack.
> > > >
> > > > Retpoline *is* a ROP gadget.  It really does modify the return address
> > > > on the stack, even if its purpose is defensive (vs Spectre v2) rather
> > > > than malicious.
> > > >
> > > > >> Whichever of these two large series lands first is going to inflict
> > > > >> fixing this problem on the other.
> > > > >>
> > > > >> As the vdso text is global (to a first approximation), it must not be a
> > > > >> retpoline if any other process is liable to want to use CET-SS.
> > > > > Why is that?
> > > >
> > > > Because when CET-SS is enabled, the ret will suffer a #CP exception
> > > > (return address on the stack not matching the one recorded in the shadow
> > > > stack), which I presume/hope is wired into SIGSEGV.
> > > >
> > >
> > > Here is the CET compatible retpoline:
> > >
> > > endbr64
> > > /* Check if shadow stack is in use.  NB: R11 is the only usable
> > >    scratch register for function calls.  */
> > > xorl %r11d, %r11d
> > > rdsspq %r11
> > > testq %r11, %r11
> > > jnz 3f
> > > call 2f
> > > 1:
> > > pause
> > > lfence
> > > jmp 1b
> > > 2:
> > > mov %rax, (%rsp)
> > > ret
> > > 3:
> > > /* Shadow stack is in use.  Make the indirect call.  */
> > > call *%rax
> > > ret
> >
> > What do we expect user programs to do on CET systems?  It would be
> > nice if we could instead ALTERNATIVE this out if X86_FEATURE_SHSTK.
> >
> > --Andy
>
> I'm open to do either solution. My thinking was to initially do things
> vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
> above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
> on details how that thing works and it should be perfectly usable for
> our use case.
>

Since SHSTK and IBT are enabled per process, not the whole machine,
are you going to patch vDSO on a per-process basis?

-- 
H.J.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 18:17             ` Dave Hansen
@ 2020-09-28 22:07               ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28 22:07 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andy Lutomirski, H.J. Lu, Andrew Cooper,
	the arch/x86 maintainers, linux-sgx, LKML, Sean Christopherson,
	Jethro Beekman, Cedric Xing, Andrew Morton, Andy Shevchenko,
	asapek, Borislav Petkov, chenalexchen, Conrad Parker, cyhanish,
	Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On Mon, Sep 28, 2020 at 11:17:42AM -0700, Dave Hansen wrote:
> On 9/28/20 11:12 AM, Andy Lutomirski wrote:
> >> endbr64
> >> /* Check if shadow stack is in use.  NB: R11 is the only usable
> >>    scratch register for function calls.  */
> >> xorl %r11d, %r11d
> >> rdsspq %r11
> >> testq %r11, %r11
> >> jnz 3f
> >> call 2f
> >> 1:
> >> pause
> >> lfence
> >> jmp 1b
> >> 2:
> >> mov %rax, (%rsp)
> >> ret
> >> 3:
> >> /* Shadow stack is in use.  Make the indirect call.  */
> >> call *%rax
> >> ret
> > What do we expect user programs to do on CET systems?  It would be
> > nice if we could instead ALTERNATIVE this out if X86_FEATURE_SHSTK.
> 
> Shouldn't we just be able to use X86_FEATURE_RETPOLINE?
> 
> We probably need a mechanism to force X86_FEATURE_SHSTK and
> X86_FEATURE_RETPOLINE to be mutually exclusive if we don't have one already.

First of all: lets go with boot time patching instead of dynamic
detection. It's both easier to implement and by all other merits makes a
lot more sense. It was just a thing that I've not used before.

That sorted out, does it matter which direction I look it at? I could
use either feature flag as basis (and I do not have a personal
preference here).

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 22:06               ` H.J. Lu
@ 2020-09-28 22:18                 ` Dave Hansen
  2020-09-28 22:41                   ` Andy Lutomirski
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-28 22:18 UTC (permalink / raw)
  To: H.J. Lu, Jarkko Sakkinen
  Cc: Andy Lutomirski, Andrew Cooper, the arch/x86 maintainers,
	linux-sgx, LKML, Sean Christopherson, Jethro Beekman,
	Cedric Xing, Andrew Morton, Andy Shevchenko, asapek,
	Borislav Petkov, chenalexchen, Conrad Parker, cyhanish, Huang,
	Haitao, Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On 9/28/20 3:06 PM, H.J. Lu wrote:
>> I'm open to do either solution. My thinking was to initially do things
>> vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
>> above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
>> on details how that thing works and it should be perfectly usable for
>> our use case.
>>
> Since SHSTK and IBT are enabled per process, not the whole machine,
> are you going to patch vDSO on a per-process basis?

No.

Retpolines mitigate Spectre v2 attacks.  If you're not vulnerable to
Spectre v2, you don't need retpolines.

All processors which support CET *also* have hardware mitigations
against Spectre v2 and don't need retpolines.  Here's all of the
possibilities:

CET=y, BUG_SPECTRE_V2=y: does not exist
CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 22:18                 ` Dave Hansen
@ 2020-09-28 22:41                   ` Andy Lutomirski
  2020-09-28 23:38                     ` Andrew Cooper
  0 siblings, 1 reply; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-28 22:41 UTC (permalink / raw)
  To: Dave Hansen
  Cc: H.J. Lu, Jarkko Sakkinen, Andy Lutomirski, Andrew Cooper,
	the arch/x86 maintainers, linux-sgx, LKML, Sean Christopherson,
	Jethro Beekman, Cedric Xing, Andrew Morton, Andy Shevchenko,
	asapek, Borislav Petkov, chenalexchen, Conrad Parker, cyhanish,
	Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 9/28/20 3:06 PM, H.J. Lu wrote:
> >> I'm open to do either solution. My thinking was to initially do things
> >> vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
> >> above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
> >> on details how that thing works and it should be perfectly usable for
> >> our use case.
> >>
> > Since SHSTK and IBT are enabled per process, not the whole machine,
> > are you going to patch vDSO on a per-process basis?
>
> No.
>
> Retpolines mitigate Spectre v2 attacks.  If you're not vulnerable to
> Spectre v2, you don't need retpolines.
>
> All processors which support CET *also* have hardware mitigations
> against Spectre v2 and don't need retpolines.  Here's all of the
> possibilities:
>
> CET=y, BUG_SPECTRE_V2=y: does not exist
> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
> CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable

Just to confirm: does this mean that the CPU mitigates against user
code mistraining the branch predictors for CPL0?  Because this is the
vDSO, and the situation we're actually concerned about is user code
mistraining its own branch predictors.  This could happen
cross-process or within the same process.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 22:41                   ` Andy Lutomirski
@ 2020-09-28 23:38                     ` Andrew Cooper
  2020-09-29 14:10                       ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Andrew Cooper @ 2020-09-28 23:38 UTC (permalink / raw)
  To: Andy Lutomirski, Dave Hansen
  Cc: H.J. Lu, Jarkko Sakkinen, the arch/x86 maintainers, linux-sgx,
	LKML, Sean Christopherson, Jethro Beekman, Cedric Xing,
	Andrew Morton, Andy Shevchenko, asapek, Borislav Petkov,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On 28/09/2020 23:41, Andy Lutomirski wrote:
> On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.hansen@intel.com> wrote:
>> On 9/28/20 3:06 PM, H.J. Lu wrote:
>>>> I'm open to do either solution. My thinking was to initially do things
>>>> vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
>>>> above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
>>>> on details how that thing works and it should be perfectly usable for
>>>> our use case.
>>>>
>>> Since SHSTK and IBT are enabled per process, not the whole machine,
>>> are you going to patch vDSO on a per-process basis?
>> No.
>>
>> Retpolines mitigate Spectre v2 attacks.  If you're not vulnerable to
>> Spectre v2, you don't need retpolines.
>>
>> All processors which support CET *also* have hardware mitigations
>> against Spectre v2 and don't need retpolines.  Here's all of the
>> possibilities:
>>
>> CET=y, BUG_SPECTRE_V2=y: does not exist
>> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
>> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>> CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
> Just to confirm: does this mean that the CPU mitigates against user
> code mistraining the branch predictors for CPL0?

If (and only if) you have eIBRS enabled.

eIBRS should be available on all CET-capable hardware, and Linux ought
to use it by default.

> Because this is the
> vDSO, and the situation we're actually concerned about is user code
> mistraining its own branch predictors.  This could happen
> cross-process or within the same process.

There is nothing (in Intel parts) which prevents mode same-mode training
of indirect branches, either in user or kernel space.

However, an IBPB on context switch should prevent cross-process trailing
attacks.

~Andrew

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 20:42         ` Jarkko Sakkinen
@ 2020-09-28 23:52           ` Andrew Cooper
  2020-09-30  0:52             ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Andrew Cooper @ 2020-09-28 23:52 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu, Yu-cheng Yu

On 28/09/2020 21:42, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
>> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
>>> On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
>>>> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
>>>>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>>>> new file mode 100644
>>>>> index 000000000000..adbd59d41517
>>>>> --- /dev/null
>>>>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
>>>>> @@ -0,0 +1,157 @@
>>>>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
>>>>> <snip>
>>>>> +.Lretpoline:
>>>>> +	call	2f
>>>>> +1:	pause
>>>>> +	lfence
>>>>> +	jmp	1b
>>>>> +2:	mov	%rax, (%rsp)
>>>>> +	ret
>>>> I hate to throw further spanners in the work, but this is not compatible
>>>> with CET, and the user shadow stack work in progress.
>>> CET goes beyond my expertise. Can you describe, at least rudimentary,
>>> how this code is not compatible?
>> CET Shadow Stacks detect attacks which modify the return address on the
>> stack.
>>
>> Retpoline *is* a ROP gadget.  It really does modify the return address
>> on the stack, even if its purpose is defensive (vs Spectre v2) rather
>> than malicious.
> Aah. I get that, yes.
>
> Kernel is full of retpoline but I presume that ring-0 does not use CET.

No-one has implemented support CET-SS support for Linux itself yet, but
other kernels do have it working.

~Andrew

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-22 14:03     ` Jarkko Sakkinen
  2020-09-22 14:24       ` Borislav Petkov
@ 2020-09-29  1:14       ` Sean Christopherson
  2020-09-29  3:50         ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-09-29  1:14 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > +	spin_lock(&sgx_active_page_list_lock);
> > > +	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> > > +		if (list_empty(&sgx_active_page_list))
> > 
> > Isn't it enough to do this once, i.e., not in the loop? You're holding
> > sgx_active_page_list_lock...

Argh, I missed this until I looked at Jarkko's updated tree.

The reason for checking list_empty() on every iteration is that the loop is
greedy, i.e. it tries to grab and reclaim up to 16 (SGX_NR_TO_SCAN) EPC pages
at a time.

> I think that would make sense. Distantly analogous to the EINIT
> discussion. Too complex code for yet to be known problem workloads I'd
> say.

Nooooo.  Please no.

This will most definitely impact workloads running a single large enclave, or a
process running multiple enclaves, as we'll lose the batching of ETRACK and IPIs.
ETRACK isn't a big deal, but the IPIs are painful and could thrash the system.
E.g. in the current code, reclaiming 10 pages from an enclave with actively
running threads will generate one round of IPIs to CPUs associated with the
enclave (based on the mm struct).  Going to per-page reclaim will likely result
in 10 rounds of IPIs as threads will reenter the enclave immediately after each
IPI wave.

Having to grab the section spinlock for every page is also (very) problematic.
Reclaiming one page at a time makes it nigh impossible for the reclaimer to
keep up as every allocation attempt acquires the spinlock.  I.e. the reclaimer
has to contend with every CPU that is faulting in an EPC page or is adding a
page to the enclave.  In my experiments with the EPC cgroup, even batching 16
pages may be insufficient to make "forward progress".  That's not an apples to
apples comparison, but it's a rough equivalent of what will happen with the
reclaim thread versus EPC page faults.  We can (and should) play with scaling
the number of reclaim threads, but at this stage, that's an exercise best left
to post-upstreaming.

I can't do A/B testing to provide numbers, because the changes in Jarkko's tree
break basic reclaim.  Which is a nice segue into my last point: this is by far
the most subtle code in the SGX code base; I really, really don't want to be
making last minute changes in this area unless they are absolutely necessary or
obviously benign.  Even if/when we get the basic reclaim functional again, and
assuming it doesn't have performance issues, I wouldn't be comfortable merging
the code without hammering it with the EPC cgroup tests for multiple days (on
top of the 1+ days to rebased the EPC cgroup).  Past testing with the cgroup
found multiple bugs with races between CPUs that required hitting a window that
was open for less than 10 instructions.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 20:19                                                             ` Jarkko Sakkinen
@ 2020-09-29  1:37                                                               ` Andy Lutomirski
  2020-09-29  4:05                                                                 ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Andy Lutomirski @ 2020-09-29  1:37 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Dave Hansen, Sean Christopherson, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx


> On Sep 28, 2020, at 1:20 PM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> 
> On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
>>> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
>>> My problem is that I fully agree what you say in your description but
>>> disagree on that EMODPE should not be mentioned.
>> 
>> I'll just be very clear: I'm not willing to ack any patch with a
>> changelog that has more than a passing mention of EMODPE.
>> 
>> Do what you think is best, but if sticking to your guns may deplete the
>> pool of folks willing to ack your patch.
> 
> I do see it mentioned in other responses too in this thread, and not
> just mine.
> 
> And here is even a request to get it to the changelog:
> 
> https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/
> 
> I'm absolutely fine not to mention EMODPE but after re-reading the
> thread, it is not like there is one voice on it. I don't really
> care all that much whether it is mentioned or not but there should
> be some reasonable logic behind the decision.

I don’t personally care that much about EMODPE but, you could probably get the point across with something like:

SGX’s EPCM permission bits do not obviate the need to enforce these rules in the PTEs because enclaves can freely modify the EPCM permissions using EMODPE.

IOW, EMODPE is not really special here; rather, EMODPE’s existence demonstrates that EADD / EEXTEND are not special.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-29  1:14       ` Sean Christopherson
@ 2020-09-29  3:50         ` Jarkko Sakkinen
  2020-09-29  8:35           ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-29  3:50 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

On Mon, Sep 28, 2020 at 06:14:39PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > +	spin_lock(&sgx_active_page_list_lock);
> > > > +	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> > > > +		if (list_empty(&sgx_active_page_list))
> > > 
> > > Isn't it enough to do this once, i.e., not in the loop? You're holding
> > > sgx_active_page_list_lock...
> 
> Argh, I missed this until I looked at Jarkko's updated tree.
> 
> The reason for checking list_empty() on every iteration is that the loop is
> greedy, i.e. it tries to grab and reclaim up to 16 (SGX_NR_TO_SCAN) EPC pages
> at a time.
> 
> > I think that would make sense. Distantly analogous to the EINIT
> > discussion. Too complex code for yet to be known problem workloads I'd
> > say.
> 
> Nooooo.  Please no.

I added this comment in the beginning of the sgx_reclaim_pages() based
on your response:

/*
 * Take a fixed number of pages from the head of the active page pool and
 * reclaim them to the enclave's private shmem files. Skip the pages, which have
 * been accessed since the last scan. Move those pages to the tail of active
 * page pool so that the pages get scanned in LRU like fashion.
 *
 * Batch process a chunk of pages (at the moment 16) in order to degrade amount
 * of IPI's and ETRACK's potentially required. sgx_encl_ewb() does degrade a bit
 * among the HW threads with three stage EWB pipeline (EWB, ETRACK + EWB and IPI
 * + EWB) but not sufficiently. Reclaiming one page at a time would also be
 * problematic as it would increase the lock contention too much, which would
 * halt forward progress.
 */

And reverted reclaimer patch as it was. Do you have anything in mind
that I should add or modify in it?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-29  1:37                                                               ` Andy Lutomirski
@ 2020-09-29  4:05                                                                 ` Jarkko Sakkinen
  2020-09-29 14:24                                                                   ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-29  4:05 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Dave Hansen, Sean Christopherson, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> I don’t personally care that much about EMODPE but, you could probably
> get the point across with something like:
> 
> SGX’s EPCM permission bits do not obviate the need to enforce these
> rules in the PTEs because enclaves can freely modify the EPCM
> permissions using EMODPE.
> 
> IOW, EMODPE is not really special here; rather, EMODPE’s existence
> demonstrates that EADD / EEXTEND are not special.

So I did "disagree and commit" with this one. I'm not actually
diagreeing on anything what Dave wrote, on the contrary it is an
understandable high level description. I just thought that it would not
hurt to remark that the ISA contains such peculiarities as EMODPE.

I did only very rudimentary clean up for the text (e.g. fix the ioctl
name, add shortt summary and not much else).

Does not make sense to waste more time to this. I'll move on to
implement the missing boot time patching for the vDSO so that we
get the next version out.

"
mm: Add 'mprotect' hook to struct vm_operations_struct

Background
==========

1. SGX enclave pages are populated with data by copying data to them
   from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
2. We want to be able to restrict those normal memory data sources.  For
   instance, before copying data to an executable enclave page, we might
   ensure that the source is executable.
3. Enclave page permissions are dynamic just like normal permissions and
   can be adjusted at runtime with mprotect() (along with a
   corresponding special instruction inside the enclave).
4. The original data source may have have long since vanished at the
   time when enclave page permission are established (mmap() or
   mprotect()).

Solution
========

The solution is to force enclaves creators to declare their intent up front
to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
compared to the source data mapping (and rejected if necessary).  It is
also stashed off and then later compared with enclave PTEs to ensure that
any future mmap()/mprotect() operations performed by the enclave creator or
the enclave itself are consistent with the earlier declared permissions.

Essentially, this means that whenever the kernel is asked to change an
enclave PTE, it needs to ensure the change is consistent with that stashed
intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
that for mmap().  However, there is no ->mprotect() hook.  Add a
vm_ops->mprotect() hook so that mprotect() operations which are
inconsistent with any page's stashed intent can be rejected by the driver.

Implications
============

However, there is currently no implementation of the intent checks at the
time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
argument (SGX_PROT_*) is currently unused.
"

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
  2020-09-29  3:50         ` Jarkko Sakkinen
@ 2020-09-29  8:35           ` Sean Christopherson
  0 siblings, 0 replies; 180+ messages in thread
From: Sean Christopherson @ 2020-09-29  8:35 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Borislav Petkov, x86, linux-sgx, linux-kernel, linux-mm,
	Jethro Beekman, Jordan Hand, Nathaniel McCallum, Chunyang Hui,
	Seth Moore, akpm, andriy.shevchenko, asapek, cedric.xing,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 29, 2020 at 06:50:10AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 06:14:39PM -0700, Sean Christopherson wrote:
> > On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > > +	spin_lock(&sgx_active_page_list_lock);
> > > > > +	for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> > > > > +		if (list_empty(&sgx_active_page_list))
> > > > 
> > > > Isn't it enough to do this once, i.e., not in the loop? You're holding
> > > > sgx_active_page_list_lock...
> > 
> > Argh, I missed this until I looked at Jarkko's updated tree.
> > 
> > The reason for checking list_empty() on every iteration is that the loop is
> > greedy, i.e. it tries to grab and reclaim up to 16 (SGX_NR_TO_SCAN) EPC pages
> > at a time.
> > 
> > > I think that would make sense. Distantly analogous to the EINIT
> > > discussion. Too complex code for yet to be known problem workloads I'd
> > > say.
> > 
> > Nooooo.  Please no.
> 
> I added this comment in the beginning of the sgx_reclaim_pages() based
> on your response:
> 
> /*
>  * Take a fixed number of pages from the head of the active page pool and
>  * reclaim them to the enclave's private shmem files. Skip the pages, which have
>  * been accessed since the last scan. Move those pages to the tail of active
>  * page pool so that the pages get scanned in LRU like fashion.
>  *
>  * Batch process a chunk of pages (at the moment 16) in order to degrade amount
>  * of IPI's and ETRACK's potentially required. sgx_encl_ewb() does degrade a bit
>  * among the HW threads with three stage EWB pipeline (EWB, ETRACK + EWB and IPI
>  * + EWB) but not sufficiently. Reclaiming one page at a time would also be
>  * problematic as it would increase the lock contention too much, which would
>  * halt forward progress.
>  */
> 
> And reverted reclaimer patch as it was. Do you have anything in mind
> that I should add or modify in it?

Nope, can't think of anything.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 23:38                     ` Andrew Cooper
@ 2020-09-29 14:10                       ` Dave Hansen
  2020-09-29 15:01                         ` Andrew Cooper
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-29 14:10 UTC (permalink / raw)
  To: Andrew Cooper, Andy Lutomirski
  Cc: H.J. Lu, Jarkko Sakkinen, the arch/x86 maintainers, linux-sgx,
	LKML, Sean Christopherson, Jethro Beekman, Cedric Xing,
	Andrew Morton, Andy Shevchenko, asapek, Borislav Petkov,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu

On 9/28/20 4:38 PM, Andrew Cooper wrote:
>>> CET=y, BUG_SPECTRE_V2=y: does not exist
>>> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
>>> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>>> CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>> Just to confirm: does this mean that the CPU mitigates against user
>> code mistraining the branch predictors for CPL0?
> If (and only if) you have eIBRS enabled.
> 
> eIBRS should be available on all CET-capable hardware, and Linux ought
> to use it by default.

You're totally right, of course.  I was (wrongly) thinking about this
VDSO retpoline as kernel code.

There's another wrinkle here.  Let's say we're vulnerable to a
Spectre-v2-style attack and we want to mitigate it on CET hardware that
has enhanced IBRS.  I'm not sure how reliable of a mitigation retpolines
are on enhanced IBRS hardware.  Intel has recommended _against_ using
them in some cases:

> https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf

"On processors that support enhanced IBRS, it should be used for
mitigation instead of retpoline."

I actually authored that bit of the whitepaper, and I recall that this
was not simply a recommendation based on performance advantages of using
enhanced IBRS.  I can dig through some old email if we decide that we
want to explore using a retpoline on enhanced IBRS hardware.

But, let's take a step back.  The changelog for this patch needs to at
least have:

1. What is the attack being mitigated by the retpoline?
2. Do we actually want to mitigate it?
3. What options are there to mitigate it?
4. Which option does this patch use and why?

Right now, there's not even a comment about this.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-29  4:05                                                                 ` Jarkko Sakkinen
@ 2020-09-29 14:24                                                                   ` Dave Hansen
  2020-09-30  0:20                                                                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Dave Hansen @ 2020-09-29 14:24 UTC (permalink / raw)
  To: Jarkko Sakkinen, Andy Lutomirski
  Cc: Sean Christopherson, Haitao Huang, Andy Lutomirski, X86 ML,
	linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
>> I don’t personally care that much about EMODPE but, you could probably
>> get the point across with something like:
>>
>> SGX’s EPCM permission bits do not obviate the need to enforce these
>> rules in the PTEs because enclaves can freely modify the EPCM
>> permissions using EMODPE.
>>
>> IOW, EMODPE is not really special here; rather, EMODPE’s existence
>> demonstrates that EADD / EEXTEND are not special.
> 
> So I did "disagree and commit" with this one. I'm not actually
> diagreeing on anything what Dave wrote, on the contrary it is an
> understandable high level description. I just thought that it would not
> hurt to remark that the ISA contains such peculiarities as EMODPE.
> 
> I did only very rudimentary clean up for the text (e.g. fix the ioctl
> name, add shortt summary and not much else).
> 
> Does not make sense to waste more time to this. I'll move on to
> implement the missing boot time patching for the vDSO so that we
> get the next version out.
> 
> "
> mm: Add 'mprotect' hook to struct vm_operations_struct
> 
> Background
> ==========
> 
> 1. SGX enclave pages are populated with data by copying data to them
>    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
> 2. We want to be able to restrict those normal memory data sources.  For
>    instance, before copying data to an executable enclave page, we might
>    ensure that the source is executable.

I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
way.  Folks dislike the use of "we" in these things.  Here's a better
version:

  2. It is desirable to be able to restrict those normal memory data
     sources.  For instance, the kernel can ensure that the source is
     executable, before copying data to an executable enclave page.

> 3. Enclave page permissions are dynamic just like normal permissions and
>    can be adjusted at runtime with mprotect() (along with a
>    corresponding special instruction inside the enclave).
> 4. The original data source may have have long since vanished at the
>    time when enclave page permission are established (mmap() or
>    mprotect()).
> 
> Solution
> ========
> 
> The solution is to force enclaves creators to declare their intent up front
> to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
> compared to the source data mapping (and rejected if necessary).  It is
> also stashed off and then later compared with enclave PTEs to ensure that
> any future mmap()/mprotect() operations performed by the enclave creator or
> the enclave itself are consistent with the earlier declared permissions.

Let's also say "... or *requested* by the enclave itself ...", since the
enclave itself can't directly make syscalls.

> Essentially, this means that whenever the kernel is asked to change an
> enclave PTE, it needs to ensure the change is consistent with that stashed
> intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
> that for mmap().  However, there is no ->mprotect() hook.  Add a
> vm_ops->mprotect() hook so that mprotect() operations which are
> inconsistent with any page's stashed intent can be rejected by the driver.
> 
> Implications
> ============
> 
> However, there is currently no implementation of the intent checks at the
> time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
> argument (SGX_PROT_*) is currently unused.

This was incorrect to say.  Sean corrected me on this point.  Could you
look through the thread and incorporate that?

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-29 14:10                       ` Dave Hansen
@ 2020-09-29 15:01                         ` Andrew Cooper
  0 siblings, 0 replies; 180+ messages in thread
From: Andrew Cooper @ 2020-09-29 15:01 UTC (permalink / raw)
  To: Dave Hansen, Andy Lutomirski
  Cc: H.J. Lu, Jarkko Sakkinen, the arch/x86 maintainers, linux-sgx,
	LKML, Sean Christopherson, Jethro Beekman, Cedric Xing,
	Andrew Morton, Andy Shevchenko, asapek, Borislav Petkov,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx,
	Yu-cheng Yu, Josh Poimboeuf

On 29/09/2020 15:10, Dave Hansen wrote:
> On 9/28/20 4:38 PM, Andrew Cooper wrote:
>>>> CET=y, BUG_SPECTRE_V2=y: does not exist
>>>> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
>>>> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>>>> CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>>> Just to confirm: does this mean that the CPU mitigates against user
>>> code mistraining the branch predictors for CPL0?
>> If (and only if) you have eIBRS enabled.
>>
>> eIBRS should be available on all CET-capable hardware, and Linux ought
>> to use it by default.
> You're totally right, of course.  I was (wrongly) thinking about this
> VDSO retpoline as kernel code.
>
> There's another wrinkle here.  Let's say we're vulnerable to a
> Spectre-v2-style attack and we want to mitigate it on CET hardware that
> has enhanced IBRS.  I'm not sure how reliable of a mitigation retpolines
> are on enhanced IBRS hardware.  Intel has recommended _against_ using
> them in some cases:
>
>> https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
> "On processors that support enhanced IBRS, it should be used for
> mitigation instead of retpoline."
> I actually authored that bit of the whitepaper, and I recall that this
> was not simply a recommendation based on performance advantages of using
> enhanced IBRS.  I can dig through some old email if we decide that we
> want to explore using a retpoline on enhanced IBRS hardware.

If only life were simple.

In light of https://arxiv.org/abs/2008.02307 which managed to
demonstrate that the original KAISER was actually a speculative attack
and nothing to do with the prefetch instruction, a discussion about
same-mode training happened.

The updated recommendation given was to continue using retpoline as well
as eIBRS to prevent same-mode training of the syscall indirect branch. 
Josh (CC'd) has been doing a lot of work to find and fix other
speculative leaks in this area.

For Skylake uarch and later, even if an RSB underflow leads to a BTB
lookup, it still requires an interrupt/NMI to hit one of two instruction
boundaries to empty the RSB, and an attacker with that level of control
probably has more interesting things to be trying to do.

Without retpoline (or something even more expensive such as IRET-ing
around), an attacker can still create speculative type confusion between
different system calls, when eIBRS is active.

Once you mix CET-SS in, this breaks, unless you're prepared to update
the retpoline gadget to include a WRSS to modify the shadow stack
alongside the regular stack.  Add this to the large pile of fun for
whomever has the privileg^W chore of implementing supervisor CET support.

>
> But, let's take a step back.  The changelog for this patch needs to at
> least have:
>
> 1. What is the attack being mitigated by the retpoline?
> 2. Do we actually want to mitigate it?
> 3. What options are there to mitigate it?
> 4. Which option does this patch use and why?
>
> Right now, there's not even a comment about this.

I agree.  The reason for using a retpoline here in the first place is
unclear.

~Andrew

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-29 14:24                                                                   ` Dave Hansen
@ 2020-09-30  0:20                                                                     ` Jarkko Sakkinen
  2020-09-30 14:35                                                                       ` Dave Hansen
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-30  0:20 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andy Lutomirski, Sean Christopherson, Haitao Huang,
	Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> >> I don’t personally care that much about EMODPE but, you could probably
> >> get the point across with something like:
> >>
> >> SGX’s EPCM permission bits do not obviate the need to enforce these
> >> rules in the PTEs because enclaves can freely modify the EPCM
> >> permissions using EMODPE.
> >>
> >> IOW, EMODPE is not really special here; rather, EMODPE’s existence
> >> demonstrates that EADD / EEXTEND are not special.
> > 
> > So I did "disagree and commit" with this one. I'm not actually
> > diagreeing on anything what Dave wrote, on the contrary it is an
> > understandable high level description. I just thought that it would not
> > hurt to remark that the ISA contains such peculiarities as EMODPE.
> > 
> > I did only very rudimentary clean up for the text (e.g. fix the ioctl
> > name, add shortt summary and not much else).
> > 
> > Does not make sense to waste more time to this. I'll move on to
> > implement the missing boot time patching for the vDSO so that we
> > get the next version out.
> > 
> > "
> > mm: Add 'mprotect' hook to struct vm_operations_struct
> > 
> > Background
> > ==========
> > 
> > 1. SGX enclave pages are populated with data by copying data to them
> >    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
> > 2. We want to be able to restrict those normal memory data sources.  For
> >    instance, before copying data to an executable enclave page, we might
> >    ensure that the source is executable.
> 
> I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
> way.  Folks dislike the use of "we" in these things.  Here's a better
> version:
> 
>   2. It is desirable to be able to restrict those normal memory data
>      sources.  For instance, the kernel can ensure that the source is
>      executable, before copying data to an executable enclave page.
> 
> > 3. Enclave page permissions are dynamic just like normal permissions and
> >    can be adjusted at runtime with mprotect() (along with a
> >    corresponding special instruction inside the enclave).
> > 4. The original data source may have have long since vanished at the
> >    time when enclave page permission are established (mmap() or
> >    mprotect()).
> > 
> > Solution
> > ========
> > 
> > The solution is to force enclaves creators to declare their intent up front
> > to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
> > compared to the source data mapping (and rejected if necessary).  It is
> > also stashed off and then later compared with enclave PTEs to ensure that
> > any future mmap()/mprotect() operations performed by the enclave creator or
> > the enclave itself are consistent with the earlier declared permissions.
> 
> Let's also say "... or *requested* by the enclave itself ...", since the
> enclave itself can't directly make syscalls.

Yes, it is definitely more understandable way to say it. Do you mind
if I rephrase it as:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or requested the enclave by itself (e.g. by issuing
ECLU[EMODPE]) are consistent with the earlier declared permissions."

I'd just mention EMODPE as an example, but I'm also perfectly fine
leaving that out :-) Not a big deal for me.

Also, should there be commas, i.e. ", or requested the enclave by
itself,"? I suck with English comma rules.

> > Essentially, this means that whenever the kernel is asked to change an
> > enclave PTE, it needs to ensure the change is consistent with that stashed
> > intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
> > that for mmap().  However, there is no ->mprotect() hook.  Add a
> > vm_ops->mprotect() hook so that mprotect() operations which are
> > inconsistent with any page's stashed intent can be rejected by the driver.
> > 
> > Implications
> > ============
> > 
> > However, there is currently no implementation of the intent checks at the
> > time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
> > argument (SGX_PROT_*) is currently unused.
> 
> This was incorrect to say.  Sean corrected me on this point.  Could you
> look through the thread and incorporate that?

OK, so we are probably talking about [1] here, right?

There are at least two checks done with and without the callback:

A. TCS pages are required to be passed with zero EPCM permissions,
   the reason being that CPU will silently overwrite its permissions
   zero. This check resides in sgx_validate_secinfo() [2].
B. noexec partitions are unconditionally disallowed. This check
   resides in __sgx_encl_add_page() [2].

TCS pages are funky in the way that they are also required to be
mapped as RW. OK, then you might argue that why not just require
RW as ioctl supplied permissions. That would cause a mismatch with
CPU calculated MRENCLAVE and one calculated to SIGSTRUCT. I've
written in past quite length explanation of this to the kdoc
of sgx_ioc_enclave_add_pages() [2].

This was something that I did not find from Sean's response.

To encompensate all this information in a paragraph, I'd write along
the lines of

"ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that
Thread Control Structure (TCS) pages are always added with zero
permissions and no pages are sourced from noexec partitions. TCS pages
are pages that work as entry points to the enclave. This is the basic
acceptance criteria for any enclave page before it gets mapped.

After finishing this, the ioctl will project the enclave permissions to
the corresponding VMA permissions and stores the result for later
lookup.  For regular pages this is an identity mapping but as an
exception TCS pages are unconditionally mapped as RW VMA permssion even
though their enclave permissions are zero. This required by the ISA.

This information will be used by sgx_mmap() and sgx_vma_protect() to
enforce that higher permissions than the projected permissions will
not be used by checking this for each every page in the address
range.

By doing this, we give assets for LSM's to make decisions during the
build time based on projected VMA permissions and the source VMA
(either a file or anonymous mapping) that hold when the enclave is
finally mapped to the visible memory."

Is this sufficient?

[1] https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#m7e84af96d63dd8ec528422cfc942f42e3bdf4356
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/kernel/cpu/sgx/ioctl.c

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-28 23:52           ` Andrew Cooper
@ 2020-09-30  0:52             ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-30  0:52 UTC (permalink / raw)
  To: Andrew Cooper, haitao.huang
  Cc: x86, linux-sgx, linux-kernel, Sean Christopherson,
	Andy Lutomirski, Jethro Beekman, Cedric Xing, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx, H.J. Lu, Yu-cheng Yu

On Tue, Sep 29, 2020 at 12:52:35AM +0100, Andrew Cooper wrote:
> On 28/09/2020 21:42, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
> >> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> >>>> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >>>>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>>>> new file mode 100644
> >>>>> index 000000000000..adbd59d41517
> >>>>> --- /dev/null
> >>>>> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >>>>> @@ -0,0 +1,157 @@
> >>>>> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> >>>>> <snip>
> >>>>> +.Lretpoline:
> >>>>> +	call	2f
> >>>>> +1:	pause
> >>>>> +	lfence
> >>>>> +	jmp	1b
> >>>>> +2:	mov	%rax, (%rsp)
> >>>>> +	ret
> >>>> I hate to throw further spanners in the work, but this is not compatible
> >>>> with CET, and the user shadow stack work in progress.
> >>> CET goes beyond my expertise. Can you describe, at least rudimentary,
> >>> how this code is not compatible?
> >> CET Shadow Stacks detect attacks which modify the return address on the
> >> stack.
> >>
> >> Retpoline *is* a ROP gadget.  It really does modify the return address
> >> on the stack, even if its purpose is defensive (vs Spectre v2) rather
> >> than malicious.
> > Aah. I get that, yes.
> >
> > Kernel is full of retpoline but I presume that ring-0 does not use CET.
> 
> No-one has implemented support CET-SS support for Linux itself yet, but
> other kernels do have it working.
> 
> ~Andrew

Haitao, can you point out the user handler callback in the Intel
SGX runtime?

There is only one single global callback in a practical deployment
provided by the runtime. AFAIK, it just copies values, does not do any
rountrips and is generally very trivial peace of code but it is better
to check it before final say.

I've now experimented with ALTERNATIVE() and it can be definitely made
work. I'm just thinking that would it be best not use retpoline at all?

My guess is that the callback would not have much applicability in
Spectre'ish attacks but do not have enough expertise on that to even
semiformally conclude it.

My intention is to find reasonable conclusions to drop it instead of
adding more complexity to the vDSO.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-30  0:20                                                                     ` Jarkko Sakkinen
@ 2020-09-30 14:35                                                                       ` Dave Hansen
  0 siblings, 0 replies; 180+ messages in thread
From: Dave Hansen @ 2020-09-30 14:35 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Andy Lutomirski, Sean Christopherson, Haitao Huang,
	Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On 9/29/20 5:20 PM, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
>> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
>>> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
>>>> I don’t personally care that much about EMODPE but, you could probably
>>>> get the point across with something like:
>>>>
>>>> SGX’s EPCM permission bits do not obviate the need to enforce these
>>>> rules in the PTEs because enclaves can freely modify the EPCM
>>>> permissions using EMODPE.
>>>>
>>>> IOW, EMODPE is not really special here; rather, EMODPE’s existence
>>>> demonstrates that EADD / EEXTEND are not special.
>>>
>>> So I did "disagree and commit" with this one. I'm not actually
>>> diagreeing on anything what Dave wrote, on the contrary it is an
>>> understandable high level description. I just thought that it would not
>>> hurt to remark that the ISA contains such peculiarities as EMODPE.
>>>
>>> I did only very rudimentary clean up for the text (e.g. fix the ioctl
>>> name, add shortt summary and not much else).
>>>
>>> Does not make sense to waste more time to this. I'll move on to
>>> implement the missing boot time patching for the vDSO so that we
>>> get the next version out.
>>>
>>> "
>>> mm: Add 'mprotect' hook to struct vm_operations_struct
>>>
>>> Background
>>> ==========
>>>
>>> 1. SGX enclave pages are populated with data by copying data to them
>>>    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
>>> 2. We want to be able to restrict those normal memory data sources.  For
>>>    instance, before copying data to an executable enclave page, we might
>>>    ensure that the source is executable.
>>
>> I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
>> way.  Folks dislike the use of "we" in these things.  Here's a better
>> version:
>>
>>   2. It is desirable to be able to restrict those normal memory data
>>      sources.  For instance, the kernel can ensure that the source is
>>      executable, before copying data to an executable enclave page.
>>
>>> 3. Enclave page permissions are dynamic just like normal permissions and
>>>    can be adjusted at runtime with mprotect() (along with a
>>>    corresponding special instruction inside the enclave).
>>> 4. The original data source may have have long since vanished at the
>>>    time when enclave page permission are established (mmap() or
>>>    mprotect()).
>>>
>>> Solution
>>> ========
>>>
>>> The solution is to force enclaves creators to declare their intent up front
>>> to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
>>> compared to the source data mapping (and rejected if necessary).  It is
>>> also stashed off and then later compared with enclave PTEs to ensure that
>>> any future mmap()/mprotect() operations performed by the enclave creator or
>>> the enclave itself are consistent with the earlier declared permissions.
>>
>> Let's also say "... or *requested* by the enclave itself ...", since the
>> enclave itself can't directly make syscalls.
> 
> Yes, it is definitely more understandable way to say it. Do you mind
> if I rephrase it as:
> 
> "It is also stashed off and then later compared with enclave PTEs to
> ensure that any future mmap()/mprotect() operations performed by the
> enclave creator or requested the enclave by itself (e.g. by issuing
> ECLU[EMODPE]) are consistent with the earlier declared permissions."
> 
> I'd just mention EMODPE as an example, but I'm also perfectly fine
> leaving that out :-) Not a big deal for me.

If I say it's a big deal for me, will you remove the bloody thing?

Mentioning EMODPE is a distraction for this patch.  It's a big
distraction because it makes it sound like it is some kind of *peer* of
mmap()/mprotect().  It's not.  It's subservient to x86 paging
protections and thus *IRRELEVANT* for this unless you care about the
intricacies of writing enclaves.

It's a big deal to me.

Also, I've tried to give this feedback previously, but the paging
permissions are also essentially irrelevant.

> Also, should there be commas, i.e. ", or requested the enclave by
> itself,"? I suck with English comma rules.

I'd just say this:

	It is also stashed off and then later compared with enclave PTEs
	to ensure that any future mmap()/mprotect() operations are
	consistent with the earlier declared permissions.

Yours was starting to look pretty run on.

> "ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that
> Thread Control Structure (TCS) pages are always added with zero
> permissions and no pages are sourced from noexec partitions. TCS pages
> are pages that work as entry points to the enclave. This is the basic
> acceptance criteria for any enclave page before it gets mapped.

This is going off into the SGX weeds again.

We don't need to justify the ABI for an ioctl() introduced in a
different patch in *THIS* patch.  Just remove this, please.

> After finishing this, the ioctl will project the enclave permissions to
> the corresponding VMA permissions and stores the result for later
> lookup.

That sounds vaguely relevant, although I'm not sure what permission
projection is.  You use that terminology over and over, so you probably
need to define it.

>  For regular pages this is an identity mapping but as an
> exception TCS pages are unconditionally mapped as RW VMA permssion even
> though their enclave permissions are zero. This required by the ISA.

I don't think this is relevant.

> This information will be used by sgx_mmap() and sgx_vma_protect() to
> enforce that higher permissions than the projected permissions will
> not be used by checking this for each every page in the address
> range.

I've given this feedback before.  Please don't use "higher" and "lower"
permissions.  "Stronger/weaker" is my preferred terminology.

You also don't have to *NAME* the functions.  If I want to know where a
structure field is, grep is a better way to find that.

Does this lose any meaning if we just say:

	This information will be to ensure that enclave PTEs will not be
	created with permissions weaker than the source data

?

> By doing this, we give assets for LSM's to make decisions during the
> build time based on projected VMA permissions and the source VMA
> (either a file or anonymous mapping) that hold when the enclave is
> finally mapped to the visible memory."

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 11/24] x86/sgx: Add SGX enclave driver
  2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
  2020-09-21  9:30   ` Borislav Petkov
@ 2020-10-01 17:36   ` Sean Christopherson
  2020-10-01 18:49     ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-10-01 17:36 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: x86, linux-sgx, linux-kernel, linux-security-module, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Suresh Siddha, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> +int __init sgx_drv_init(void)
> +{
> +	unsigned int eax, ebx, ecx, edx;
> +	u64 attr_mask, xfrm_mask;
> +	int ret;
> +	int i;
> +
> +	if (!boot_cpu_has(X86_FEATURE_SGX_LC)) {
> +		pr_info("The public key MSRs are not writable.\n");
> +		return -ENODEV;
> +	}
> +
> +	cpuid_count(SGX_CPUID, 0, &eax, &ebx, &ecx, &edx);
> +	sgx_misc_reserved_mask = ~ebx | SGX_MISC_RESERVED_MASK;
> +	sgx_encl_size_max_64 = 1ULL << ((edx >> 8) & 0xFF);
> +	sgx_encl_size_max_32 = 1ULL << (edx & 0xFF);
> +
> +	cpuid_count(SGX_CPUID, 1, &eax, &ebx, &ecx, &edx);
> +
> +	attr_mask = (((u64)ebx) << 32) + (u64)eax;
> +	sgx_attributes_reserved_mask = ~attr_mask | SGX_ATTR_RESERVED_MASK;
> +
> +	if (boot_cpu_has(X86_FEATURE_OSXSAVE)) {
> +		xfrm_mask = (((u64)edx) << 32) + (u64)ecx;
> +
> +		for (i = 2; i < 64; i++) {
> +			cpuid_count(0x0D, i, &eax, &ebx, &ecx, &edx);
> +			if ((1UL << i) & xfrm_mask)

Any reason not to use BIT()?  The max size computations are arguably not
bit operation, but XFRM is a set of bits.

> +				sgx_xsave_size_tbl[i] = eax + ebx;
> +		}
> +
> +		sgx_xfrm_reserved_mask = ~xfrm_mask;
> +	}
> +
> +	ret = misc_register(&sgx_dev_enclave);
> +	if (ret) {
> +		pr_err("Creating /dev/sgx/enclave failed with %d.\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 11/24] x86/sgx: Add SGX enclave driver
  2020-10-01 17:36   ` Sean Christopherson
@ 2020-10-01 18:49     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-10-01 18:49 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: x86, linux-sgx, linux-kernel, linux-security-module, linux-mm,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Haitao Huang,
	Chunyang Hui, Jordan Hand, Nathaniel McCallum, Seth Moore,
	Darren Kenny, Suresh Siddha, andriy.shevchenko, asapek, bp,
	cedric.xing, chenalexchen, conradparker, cyhanish, dave.hansen,
	haitao.huang, josh, kai.huang, kai.svahn, kmoy, ludloff, luto,
	nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Thu, Oct 01, 2020 at 10:36:53AM -0700, Sean Christopherson wrote:
> On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> > +int __init sgx_drv_init(void)
> > +{
> > +	unsigned int eax, ebx, ecx, edx;
> > +	u64 attr_mask, xfrm_mask;
> > +	int ret;
> > +	int i;
> > +
> > +	if (!boot_cpu_has(X86_FEATURE_SGX_LC)) {
> > +		pr_info("The public key MSRs are not writable.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	cpuid_count(SGX_CPUID, 0, &eax, &ebx, &ecx, &edx);
> > +	sgx_misc_reserved_mask = ~ebx | SGX_MISC_RESERVED_MASK;
> > +	sgx_encl_size_max_64 = 1ULL << ((edx >> 8) & 0xFF);
> > +	sgx_encl_size_max_32 = 1ULL << (edx & 0xFF);
> > +
> > +	cpuid_count(SGX_CPUID, 1, &eax, &ebx, &ecx, &edx);
> > +
> > +	attr_mask = (((u64)ebx) << 32) + (u64)eax;
> > +	sgx_attributes_reserved_mask = ~attr_mask | SGX_ATTR_RESERVED_MASK;
> > +
> > +	if (boot_cpu_has(X86_FEATURE_OSXSAVE)) {
> > +		xfrm_mask = (((u64)edx) << 32) + (u64)ecx;
> > +
> > +		for (i = 2; i < 64; i++) {
> > +			cpuid_count(0x0D, i, &eax, &ebx, &ecx, &edx);
> > +			if ((1UL << i) & xfrm_mask)
> 
> Any reason not to use BIT()?  The max size computations are arguably not
> bit operation, but XFRM is a set of bits.

AFAIK, yes.

If you have bandwidth drop a patch for this and provision thing. I'm
busy with the documentation. If not, that's fine, I'll do it once I'm
able to.

Thanks.

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-09-15 11:28 ` [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
  2020-09-21 10:03   ` Borislav Petkov
@ 2020-10-03  0:23   ` Haitao Huang
  2020-10-03  3:24     ` Jarkko Sakkinen
  1 sibling, 1 reply; 180+ messages in thread
From: Haitao Huang @ 2020-10-03  0:23 UTC (permalink / raw)
  To: x86, linux-sgx, Jarkko Sakkinen
  Cc: linux-kernel, Jethro Beekman, Chunyang Hui, Jordan Hand,
	Nathaniel McCallum, Seth Moore, Darren Kenny,
	Sean Christopherson, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Tue, 15 Sep 2020 06:28:30 -0500, Jarkko Sakkinen  
<jarkko.sakkinen@linux.intel.com> wrote:

> Add an ioctl that performs ENCLS[ECREATE], which creates SGX Enclave
> Control Structure for the enclave. SECS contains attributes about the
> enclave that are used by the hardware and cannot be directly accessed by
> software, as SECS resides in the EPC.
>
> One essential field in SECS is a field that stores the SHA256 of the
> measured enclave pages. This field, MRENCLAVE, is initialized by the
> ECREATE instruction and updated by every EADD and EEXTEND operation.
> Finally, EINIT locks down the value.
>
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Tested-by: Jethro Beekman <jethro@fortanix.com>
> Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
> Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
> Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
> Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
> Tested-by: Seth Moore <sethmo@google.com>
> Tested-by: Darren Kenny <darren.kenny@oracle.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  .../userspace-api/ioctl/ioctl-number.rst      |   1 +
>  arch/x86/include/uapi/asm/sgx.h               |  25 ++
>  arch/x86/kernel/cpu/sgx/Makefile              |   1 +
>  arch/x86/kernel/cpu/sgx/driver.c              |  12 +
>  arch/x86/kernel/cpu/sgx/driver.h              |   1 +
>  arch/x86/kernel/cpu/sgx/ioctl.c               | 220 ++++++++++++++++++
>  6 files changed, 260 insertions(+)
>  create mode 100644 arch/x86/include/uapi/asm/sgx.h
>  create mode 100644 arch/x86/kernel/cpu/sgx/ioctl.c
>
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst  
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 2a198838fca9..a89e1c46a25a 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -323,6 +323,7 @@ Code  Seq#    Include  
> File                                           Comments
>                                                                       <mailto:tlewis@mindspring.com>
>  0xA3  90-9F  linux/dtlk.h
>  0xA4  00-1F  uapi/linux/tee.h                                         
> Generic TEE subsystem
> +0xA4  00-1F  uapi/asm/sgx.h                                           
> <mailto:linux-sgx@vger.kernel.org>
>  0xAA  00-3F  linux/uapi/linux/userfaultfd.h
>  0xAB  00-1F  linux/nbd.h
>  0xAC  00-1F  linux/raw.h
> diff --git a/arch/x86/include/uapi/asm/sgx.h  
> b/arch/x86/include/uapi/asm/sgx.h
> new file mode 100644
> index 000000000000..c75b375f3770
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/sgx.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: ((GPL-2.0+ WITH Linux-syscall-note) OR  
> BSD-3-Clause) */
> +/*
> + * Copyright(c) 2016-19 Intel Corporation.
> + */
> +#ifndef _UAPI_ASM_X86_SGX_H
> +#define _UAPI_ASM_X86_SGX_H
> +
> +#include <linux/types.h>
> +#include <linux/ioctl.h>
> +
> +#define SGX_MAGIC 0xA4
> +
> +#define SGX_IOC_ENCLAVE_CREATE \
> +	_IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
> +
> +/**
> + * struct sgx_enclave_create - parameter structure for the
> + *                             %SGX_IOC_ENCLAVE_CREATE ioctl
> + * @src:	address for the SECS page data
> + */
> +struct sgx_enclave_create  {
> +	__u64	src;
> +};
> +
> +#endif /* _UAPI_ASM_X86_SGX_H */
> diff --git a/arch/x86/kernel/cpu/sgx/Makefile  
> b/arch/x86/kernel/cpu/sgx/Makefile
> index 3fc451120735..91d3dc784a29 100644
> --- a/arch/x86/kernel/cpu/sgx/Makefile
> +++ b/arch/x86/kernel/cpu/sgx/Makefile
> @@ -1,4 +1,5 @@
>  obj-y += \
>  	driver.o \
>  	encl.o \
> +	ioctl.o \
>  	main.o
> diff --git a/arch/x86/kernel/cpu/sgx/driver.c  
> b/arch/x86/kernel/cpu/sgx/driver.c
> index f54da5f19c2b..7bdb49dfcca6 100644
> --- a/arch/x86/kernel/cpu/sgx/driver.c
> +++ b/arch/x86/kernel/cpu/sgx/driver.c
> @@ -114,10 +114,22 @@ static unsigned long sgx_get_unmapped_area(struct  
> file *file,
>  	return current->mm->get_unmapped_area(file, addr, len, pgoff, flags);
>  }
> +#ifdef CONFIG_COMPAT
> +static long sgx_compat_ioctl(struct file *filep, unsigned int cmd,
> +			      unsigned long arg)
> +{
> +	return sgx_ioctl(filep, cmd, arg);
> +}
> +#endif
> +
>  static const struct file_operations sgx_encl_fops = {
>  	.owner			= THIS_MODULE,
>  	.open			= sgx_open,
>  	.release		= sgx_release,
> +	.unlocked_ioctl		= sgx_ioctl,
> +#ifdef CONFIG_COMPAT
> +	.compat_ioctl		= sgx_compat_ioctl,
> +#endif
>  	.mmap			= sgx_mmap,
>  	.get_unmapped_area	= sgx_get_unmapped_area,
>  };
> diff --git a/arch/x86/kernel/cpu/sgx/driver.h  
> b/arch/x86/kernel/cpu/sgx/driver.h
> index f7ce40dedc91..e4063923115b 100644
> --- a/arch/x86/kernel/cpu/sgx/driver.h
> +++ b/arch/x86/kernel/cpu/sgx/driver.h
> @@ -9,6 +9,7 @@
>  #include <linux/rwsem.h>
>  #include <linux/sched.h>
>  #include <linux/workqueue.h>
> +#include <uapi/asm/sgx.h>
>  #include "sgx.h"
> #define SGX_EINIT_SPIN_COUNT	20
> diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c  
> b/arch/x86/kernel/cpu/sgx/ioctl.c
> new file mode 100644
> index 000000000000..352a3c461812
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/sgx/ioctl.c
> @@ -0,0 +1,220 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +// Copyright(c) 2016-19 Intel Corporation.
> +
> +#include <asm/mman.h>
> +#include <linux/mman.h>
> +#include <linux/delay.h>
> +#include <linux/file.h>
> +#include <linux/hashtable.h>
> +#include <linux/highmem.h>
> +#include <linux/ratelimit.h>
> +#include <linux/sched/signal.h>
> +#include <linux/shmem_fs.h>
> +#include <linux/slab.h>
> +#include <linux/suspend.h>
> +#include "driver.h"
> +#include "encl.h"
> +#include "encls.h"
> +
> +static u32 sgx_calc_ssa_frame_size(u32 miscselect, u64 xfrm)
> +{
> +	u32 size_max = PAGE_SIZE;
> +	u32 size;
> +	int i;
> +
> +	for (i = 2; i < 64; i++) {
> +		if (!((1 << i) & xfrm))
> +			continue;
> +
> +		size = SGX_SSA_GPRS_SIZE + sgx_xsave_size_tbl[i];
> +
> +		if (miscselect & SGX_MISC_EXINFO)
> +			size += SGX_SSA_MISC_EXINFO_SIZE;
> +
> +		if (size > size_max)
> +			size_max = size;
> +	}
> +
> +	return PFN_UP(size_max);
> +}
> +
> +static int sgx_validate_secs(const struct sgx_secs *secs)
> +{
> +	u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
> +		       sgx_encl_size_max_64 : sgx_encl_size_max_32;
> +
> +	if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> +		return -EINVAL;
> +
> +	if (secs->base & (secs->size - 1))
> +		return -EINVAL;
> +
> +	if (secs->miscselect & sgx_misc_reserved_mask ||
> +	    secs->attributes & sgx_attributes_reserved_mask ||
> +	    secs->xfrm & sgx_xfrm_reserved_mask)
> +		return -EINVAL;
> +

Attributes should not be enforced against what's available on platform but  
checked and enforced against the mask for enforcement in sigstruct. For  
example an enclave could opt to sign with AVX bit in xfrm, but still be  
loadable on a platform without it if the sigstruct->body.attributes_mask  
does not turn that bit on.

Suggest to remove the above check,and do following during EINIt in  
sgx_encl_init:

-       /* Check that the required attributes have been authorized. */
+       /* Check that the requested attributes have been authorized. */
         if (encl->secs_attributes & ~encl->allowed_attributes)
                 return -EACCES;

+       /* Check that mandatory features are supported. */
+       if (sigstruct->body.attributes & sigstruct->body.attributes_mask &
+           sgx_attributes_reserved_mask)
+               return -EINVAL;
+       if (sigstruct->body.miscselect & sigstruct->body.misc_mask &
+           sgx_misc_reserved_mask)
+               return -EINVAL;
+       if (sigstruct->body.xfrm & sigstruct->body.xfrm_mask &
+           sgx_xfrm_reserved_mask)
+               return -EINVAL;
+
         ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);

Haitao

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
  2020-10-03  0:23   ` Haitao Huang
@ 2020-10-03  3:24     ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-10-03  3:24 UTC (permalink / raw)
  To: Haitao Huang
  Cc: x86, linux-sgx, linux-kernel, Jethro Beekman, Chunyang Hui,
	Jordan Hand, Nathaniel McCallum, Seth Moore, Darren Kenny,
	Sean Christopherson, Suresh Siddha, akpm, andriy.shevchenko,
	asapek, bp, cedric.xing, chenalexchen, conradparker, cyhanish,
	dave.hansen, haitao.huang, josh, kai.huang, kai.svahn, kmoy,
	ludloff, luto, nhorman, puiterwijk, rientjes, tglx, yaozhangx

On Fri, Oct 02, 2020 at 07:23:55PM -0500, Haitao Huang wrote:
> On Tue, 15 Sep 2020 06:28:30 -0500, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> 
> > Add an ioctl that performs ENCLS[ECREATE], which creates SGX Enclave
> > Control Structure for the enclave. SECS contains attributes about the
> > enclave that are used by the hardware and cannot be directly accessed by
> > software, as SECS resides in the EPC.
> > 
> > One essential field in SECS is a field that stores the SHA256 of the
> > measured enclave pages. This field, MRENCLAVE, is initialized by the
> > ECREATE instruction and updated by every EADD and EEXTEND operation.
> > Finally, EINIT locks down the value.
> > 
> > Acked-by: Jethro Beekman <jethro@fortanix.com>
> > Tested-by: Jethro Beekman <jethro@fortanix.com>
> > Tested-by: Haitao Huang <haitao.huang@linux.intel.com>
> > Tested-by: Chunyang Hui <sanqian.hcy@antfin.com>
> > Tested-by: Jordan Hand <jorhand@linux.microsoft.com>
> > Tested-by: Nathaniel McCallum <npmccallum@redhat.com>
> > Tested-by: Seth Moore <sethmo@google.com>
> > Tested-by: Darren Kenny <darren.kenny@oracle.com>
> > Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> > Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
> > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> >  .../userspace-api/ioctl/ioctl-number.rst      |   1 +
> >  arch/x86/include/uapi/asm/sgx.h               |  25 ++
> >  arch/x86/kernel/cpu/sgx/Makefile              |   1 +
> >  arch/x86/kernel/cpu/sgx/driver.c              |  12 +
> >  arch/x86/kernel/cpu/sgx/driver.h              |   1 +
> >  arch/x86/kernel/cpu/sgx/ioctl.c               | 220 ++++++++++++++++++
> >  6 files changed, 260 insertions(+)
> >  create mode 100644 arch/x86/include/uapi/asm/sgx.h
> >  create mode 100644 arch/x86/kernel/cpu/sgx/ioctl.c
> > 
> > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > index 2a198838fca9..a89e1c46a25a 100644
> > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > @@ -323,6 +323,7 @@ Code  Seq#    Include File
> > Comments
> >                                                                       <mailto:tlewis@mindspring.com>
> >  0xA3  90-9F  linux/dtlk.h
> >  0xA4  00-1F  uapi/linux/tee.h
> > Generic TEE subsystem
> > +0xA4  00-1F  uapi/asm/sgx.h
> > <mailto:linux-sgx@vger.kernel.org>
> >  0xAA  00-3F  linux/uapi/linux/userfaultfd.h
> >  0xAB  00-1F  linux/nbd.h
> >  0xAC  00-1F  linux/raw.h
> > diff --git a/arch/x86/include/uapi/asm/sgx.h
> > b/arch/x86/include/uapi/asm/sgx.h
> > new file mode 100644
> > index 000000000000..c75b375f3770
> > --- /dev/null
> > +++ b/arch/x86/include/uapi/asm/sgx.h
> > @@ -0,0 +1,25 @@
> > +/* SPDX-License-Identifier: ((GPL-2.0+ WITH Linux-syscall-note) OR
> > BSD-3-Clause) */
> > +/*
> > + * Copyright(c) 2016-19 Intel Corporation.
> > + */
> > +#ifndef _UAPI_ASM_X86_SGX_H
> > +#define _UAPI_ASM_X86_SGX_H
> > +
> > +#include <linux/types.h>
> > +#include <linux/ioctl.h>
> > +
> > +#define SGX_MAGIC 0xA4
> > +
> > +#define SGX_IOC_ENCLAVE_CREATE \
> > +	_IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
> > +
> > +/**
> > + * struct sgx_enclave_create - parameter structure for the
> > + *                             %SGX_IOC_ENCLAVE_CREATE ioctl
> > + * @src:	address for the SECS page data
> > + */
> > +struct sgx_enclave_create  {
> > +	__u64	src;
> > +};
> > +
> > +#endif /* _UAPI_ASM_X86_SGX_H */
> > diff --git a/arch/x86/kernel/cpu/sgx/Makefile
> > b/arch/x86/kernel/cpu/sgx/Makefile
> > index 3fc451120735..91d3dc784a29 100644
> > --- a/arch/x86/kernel/cpu/sgx/Makefile
> > +++ b/arch/x86/kernel/cpu/sgx/Makefile
> > @@ -1,4 +1,5 @@
> >  obj-y += \
> >  	driver.o \
> >  	encl.o \
> > +	ioctl.o \
> >  	main.o
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> > b/arch/x86/kernel/cpu/sgx/driver.c
> > index f54da5f19c2b..7bdb49dfcca6 100644
> > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -114,10 +114,22 @@ static unsigned long sgx_get_unmapped_area(struct
> > file *file,
> >  	return current->mm->get_unmapped_area(file, addr, len, pgoff, flags);
> >  }
> > +#ifdef CONFIG_COMPAT
> > +static long sgx_compat_ioctl(struct file *filep, unsigned int cmd,
> > +			      unsigned long arg)
> > +{
> > +	return sgx_ioctl(filep, cmd, arg);
> > +}
> > +#endif
> > +
> >  static const struct file_operations sgx_encl_fops = {
> >  	.owner			= THIS_MODULE,
> >  	.open			= sgx_open,
> >  	.release		= sgx_release,
> > +	.unlocked_ioctl		= sgx_ioctl,
> > +#ifdef CONFIG_COMPAT
> > +	.compat_ioctl		= sgx_compat_ioctl,
> > +#endif
> >  	.mmap			= sgx_mmap,
> >  	.get_unmapped_area	= sgx_get_unmapped_area,
> >  };
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.h
> > b/arch/x86/kernel/cpu/sgx/driver.h
> > index f7ce40dedc91..e4063923115b 100644
> > --- a/arch/x86/kernel/cpu/sgx/driver.h
> > +++ b/arch/x86/kernel/cpu/sgx/driver.h
> > @@ -9,6 +9,7 @@
> >  #include <linux/rwsem.h>
> >  #include <linux/sched.h>
> >  #include <linux/workqueue.h>
> > +#include <uapi/asm/sgx.h>
> >  #include "sgx.h"
> > #define SGX_EINIT_SPIN_COUNT	20
> > diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c
> > b/arch/x86/kernel/cpu/sgx/ioctl.c
> > new file mode 100644
> > index 000000000000..352a3c461812
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/sgx/ioctl.c
> > @@ -0,0 +1,220 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +// Copyright(c) 2016-19 Intel Corporation.
> > +
> > +#include <asm/mman.h>
> > +#include <linux/mman.h>
> > +#include <linux/delay.h>
> > +#include <linux/file.h>
> > +#include <linux/hashtable.h>
> > +#include <linux/highmem.h>
> > +#include <linux/ratelimit.h>
> > +#include <linux/sched/signal.h>
> > +#include <linux/shmem_fs.h>
> > +#include <linux/slab.h>
> > +#include <linux/suspend.h>
> > +#include "driver.h"
> > +#include "encl.h"
> > +#include "encls.h"
> > +
> > +static u32 sgx_calc_ssa_frame_size(u32 miscselect, u64 xfrm)
> > +{
> > +	u32 size_max = PAGE_SIZE;
> > +	u32 size;
> > +	int i;
> > +
> > +	for (i = 2; i < 64; i++) {
> > +		if (!((1 << i) & xfrm))
> > +			continue;
> > +
> > +		size = SGX_SSA_GPRS_SIZE + sgx_xsave_size_tbl[i];
> > +
> > +		if (miscselect & SGX_MISC_EXINFO)
> > +			size += SGX_SSA_MISC_EXINFO_SIZE;
> > +
> > +		if (size > size_max)
> > +			size_max = size;
> > +	}
> > +
> > +	return PFN_UP(size_max);
> > +}
> > +
> > +static int sgx_validate_secs(const struct sgx_secs *secs)
> > +{
> > +	u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
> > +		       sgx_encl_size_max_64 : sgx_encl_size_max_32;
> > +
> > +	if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> > +		return -EINVAL;
> > +
> > +	if (secs->base & (secs->size - 1))
> > +		return -EINVAL;
> > +
> > +	if (secs->miscselect & sgx_misc_reserved_mask ||
> > +	    secs->attributes & sgx_attributes_reserved_mask ||
> > +	    secs->xfrm & sgx_xfrm_reserved_mask)
> > +		return -EINVAL;
> > +
> 
> Attributes should not be enforced against what's available on platform but
> checked and enforced against the mask for enforcement in sigstruct. For
> example an enclave could opt to sign with AVX bit in xfrm, but still be
> loadable on a platform without it if the sigstruct->body.attributes_mask
> does not turn that bit on.
> 
> Suggest to remove the above check,and do following during EINIt in
> sgx_encl_init:
> 
> -       /* Check that the required attributes have been authorized. */
> +       /* Check that the requested attributes have been authorized. */

This is as bad and useless comment as the existing was. In the paragraph
you wrote above you state the things that are useful.

So: I'll take the code change and put the response above here instead
because it is says the right things :-) (maybe with very minor edit)

>         if (encl->secs_attributes & ~encl->allowed_attributes)
>                 return -EACCES;
> 
> +       /* Check that mandatory features are supported. */
> +       if (sigstruct->body.attributes & sigstruct->body.attributes_mask &
> +           sgx_attributes_reserved_mask)
> +               return -EINVAL;
> +       if (sigstruct->body.miscselect & sigstruct->body.misc_mask &
> +           sgx_misc_reserved_mask)
> +               return -EINVAL;
> +       if (sigstruct->body.xfrm & sigstruct->body.xfrm_mask &
> +           sgx_xfrm_reserved_mask)
> +               return -EINVAL;
> +
>         ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);
> 
> Haitao

Thanks a lot!

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-09-28 14:04                                                   ` Dave Hansen
  2020-09-28 16:19                                                     ` Jarkko Sakkinen
@ 2020-10-18  8:49                                                     ` Dr. Greg
  2020-10-19 21:31                                                       ` Sean Christopherson
  1 sibling, 1 reply; 180+ messages in thread
From: Dr. Greg @ 2020-10-18  8:49 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Jarkko Sakkinen, Sean Christopherson, Haitao Huang,
	Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:

Good morning, I hope the weekend is going well for everyone.

> On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> >> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >>>> That means that the intent argument (SGX_PROT_*) is currently unused.
> >>> No, the intent argument is used (eventually) by SGX's ->mprotect()
> >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> >>> subset of the declared/intended protections.
> >>>
> >>> If ->mprotect() is not merged, then it yes, it will be unused.
> >>
> >> OK, I think I've got it.
> >>
> >> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> >> argument that intent needs to be checked at mmap() time, they obviously
> >> need to be checked at mprotect() too.
> >>
> >> Jarkko, if you want to try and rewrite the changelog, capturing the
> >> discussion here and reply, I think I can ack the resulting patch.  I
> >> don't know if that will satisfy the request from Boris from an ack from
> >> a "mm person", but we can at least start there. :)
> > 
> > I think what it needs, based on what I've read, is the step by step
> > description of the EMODPE scenarion without this callback and with it.
> 
> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> permissions still specify the most restrictive permissions, which is
> what matters the most.
> 
> We care about the _worst_ the enclave can do, not what it imposes on
> itself on top of that.
> 
> > I think other important thing to underline is that an LSM or any other
> > security measure can only do a sane decision when the enclave is loaded.
> > At that point we know the source (vm_file).
> 
> Right, you know the source, but it can be anonymous or a file.

Or it could be loaded over the network in encrypted form by the
enclave itself.

Sean, admirably, wants to peer into the future and set the driver up
from an architectural perspective, to future proof it for the
imposition of security controls.  So it would seem helpful to peer a
bit.

If I can paraphrase/simplify the discussion to date; the best the
kernel can do with respect to SGX is to impose controls, via mprotect,
that limit the maximum permissions of an enclave page to whatever was
specified when the enclave was loaded/initialized.

So here is the question that would seem to need answering:

Is this even a relevant control if we cede the notion of dynamically
loadable enclave code, which is the objective of SGX2 hardware, which
will in all likelihood be the only relevant hardware implementation in
the future?

The answer to this could very well be yes if the objective is to
provide a method for a platform owner to explicitly block dynamically
loadable enclave code.  Since there seems to be a desire for immense
clarity in the changelogs surrounding all of this, framing the
discussion in something practical like this may be of assistance.

One of the desires of the SGX user community is to not allow
visibility into enclave code, this is one of the notions/objectives of
confidential computing.  The Protected Code Loader that was added by
Intel to their PSW is an acknowledgement of this fact.  EDMM and
dynamically loadable code makes doing this much more efficient so that
would seem to be the face of the future.

My apologies for 'delaying' the driver even more.  I was accused of
that about a year ago but it appears I didn't do too much
damage... :-)

Best wishes for a productive week.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
                                -- Cowboy Wisdom

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-10-18  8:49                                                     ` Dr. Greg
@ 2020-10-19 21:31                                                       ` Sean Christopherson
  2020-10-20 10:01                                                         ` Dr. Greg
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-10-19 21:31 UTC (permalink / raw)
  To: Dr. Greg
  Cc: Dave Hansen, Jarkko Sakkinen, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> Is this even a relevant control if we cede the notion of dynamically
> loadable enclave code, which is the objective of SGX2 hardware, which
> will in all likelihood be the only relevant hardware implementation in
> the future?

Yes, it's still relevant.  Giving the thumbs up to dynamically loadable code is
not a purely binary decision, e.g. a user/admin can allow RW->RX transitions
but still disallow full RWX permissions.

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-10-19 21:31                                                       ` Sean Christopherson
@ 2020-10-20 10:01                                                         ` Dr. Greg
  2020-10-20 16:40                                                           ` Sean Christopherson
  0 siblings, 1 reply; 180+ messages in thread
From: Dr. Greg @ 2020-10-20 10:01 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Dave Hansen, Jarkko Sakkinen, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote:

Good morning, I hope the day is starting well for everyone.

> On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> > Is this even a relevant control if we cede the notion of dynamically
> > loadable enclave code, which is the objective of SGX2 hardware, which
> > will in all likelihood be the only relevant hardware implementation in
> > the future?

> Yes, it's still relevant.  Giving the thumbs up to dynamically
> loadable code is not a purely binary decision, e.g. a user/admin can
> allow RW->RX transitions but still disallow full RWX permissions.

With respect to the security issue at hand, the only relevant issue
would seem to be if a page had write permissions at one time in its
trajectory to having execute permisions, isn't this correct?

The next paragraph of my reply wasn't included in your reply, but I
did state that the mprotect hook would be relevant if its purpose was
to disallow this permission trajectory and in the process disable
enclave dynamic code loading and execution.

So to assist everyone in understanding this issue and the security
implications involved, is the ultimate purpose of the mprotect hook to
disable dynamic code loading?

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: dg@enjellic.com
------------------------------------------------------------------------------
"Those who will not study history are doomed to debug it."
                                -- Barry Shein

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-10-20 10:01                                                         ` Dr. Greg
@ 2020-10-20 16:40                                                           ` Sean Christopherson
  2020-10-24 14:37                                                             ` Dr. Greg
  0 siblings, 1 reply; 180+ messages in thread
From: Sean Christopherson @ 2020-10-20 16:40 UTC (permalink / raw)
  To: Dr. Greg
  Cc: Dave Hansen, Jarkko Sakkinen, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote:
> 
> Good morning, I hope the day is starting well for everyone.
> 
> > On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> > > Is this even a relevant control if we cede the notion of dynamically
> > > loadable enclave code, which is the objective of SGX2 hardware, which
> > > will in all likelihood be the only relevant hardware implementation in
> > > the future?
> 
> > Yes, it's still relevant.  Giving the thumbs up to dynamically
> > loadable code is not a purely binary decision, e.g. a user/admin can
> > allow RW->RX transitions but still disallow full RWX permissions.
> 
> With respect to the security issue at hand, the only relevant issue
> would seem to be if a page had write permissions at one time in its
> trajectory to having execute permisions, isn't this correct?

No.  RW->RX has different properties than RWX.  E.g. an enclave that
dynamically loads code is not the same thing as an enclave that allows
simultaneously writing and executing a page.

> The next paragraph of my reply wasn't included in your reply, but I
> did state that the mprotect hook would be relevant if its purpose was
> to disallow this permission trajectory and in the process disable
> enclave dynamic code loading and execution.
> 
> So to assist everyone in understanding this issue and the security
> implications involved, is the ultimate purpose of the mprotect hook to
> disable dynamic code loading?

No, it's to provide line of sight to enforcing granular LSM checks on enclave
pages.  Jumping back to the RWX thing, as a defense in depth measure, a policy
owner could set an SELinux policy to never allow RWX, even for enclaves that
dynamically load code.

Whether or not having per-page granluarity on enclave permission checks is
valuable/interesting is debatable, e.g. it's why LSM integration is notably
absent from the this series.  But, adding the ->mprotect() hook is relatively
cheap and can always be removed if it's deemed unnecessary in the long run.
The reverse is not true; omitting ->mprotect() commits the kernel to an ABI
that is either ugly and potentially painful (require all enclaves to declare
full RWX permissions), or flat out prevents adding granular LSM support in
the future (do nothing).

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-10-20 16:40                                                           ` Sean Christopherson
@ 2020-10-24 14:37                                                             ` Dr. Greg
  2020-10-24 15:33                                                               ` Andy Lutomirski
  0 siblings, 1 reply; 180+ messages in thread
From: Dr. Greg @ 2020-10-24 14:37 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: Dave Hansen, Jarkko Sakkinen, Haitao Huang, Andy Lutomirski,
	X86 ML, linux-sgx, LKML, Linux-MM, Andrew Morton, Matthew Wilcox,
	Jethro Beekman, Darren Kenny, Andy Shevchenko, asapek,
	Borislav Petkov, Xing, Cedric, chenalexchen, Conrad Parker,
	cyhanish, Huang, Haitao, Josh Triplett, Huang, Kai, Svahn, Kai,
	Keith Moyer, Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx

On Tue, Oct 20, 2020 at 09:40:00AM -0700, Sean Christopherson wrote:

Good morning, I hope the week has gone well for everyone.

> On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> >
> > With respect to the security issue at hand, the only relevant issue
> > would seem to be if a page had write permissions at one time in its
> > trajectory to having execute permisions, isn't this correct?

> No.  RW->RX has different properties than RWX.  E.g. an enclave that
> dynamically loads code is not the same thing as an enclave that
> allows simultaneously writing and executing a page.

Yes, it is certainly correct that a platform administrator may want to
restrict RWX, given that it makes an enclave susceptible to potential
arbitrary code execution if there is a programming error in the
enclave.

However, I think it is important for everyone interested in these
issues, to reflect back on what started all of this and that was
Andy's concern that the initial incantations of the driver allowed
execution of arbitrary memory without the ability of the LSM to get a
'look' at the code/memory.

My point in all of this is that a permissions trajectory for an
enclave that allows for write permissions on a path that terminates in
X permissions opens the door for arbitrary memory execution that the
platform security architect has no insight into or that the LSM will
have any control over.

There is no guarantee that dynamically loaded code has to come into
the enclave via anything that the operating system has visibility
into.  If the enclave can toggle RW->RX it is free to dynamically load
code, in encrypted form over the network and then execute it.

In fact, I would posit that this model will be a primary use for
dynamic code loading.  The SGX user community views 'confidential
computing' as much about protecting visibility into algorithms and
code as it is about data that is being operated on.  In certain
unnamed venues where I have consulted it is the primary concern.

So in the broadest sense, we have spent a year worrying about if and
how the LSM will have visibility into enclave based code and in the
end the only really relevant security mechanism available is limiting
page permission transitions that prevent dynamic code loading.  Modulo
of course the issue with RWX, where a platform owner may elect to try
and prevent an enclave writer from shooting themselves in the foot.

The issue at hand is that the primary security threat of the
technology is the same as what the user community wants to use it for.
Joanna Rutkowska called that out a half decade ago when she first
reviewed the technology.

> > The next paragraph of my reply wasn't included in your reply, but I
> > did state that the mprotect hook would be relevant if its purpose was
> > to disallow this permission trajectory and in the process disable
> > enclave dynamic code loading and execution.
> > 
> > So to assist everyone in understanding this issue and the security
> > implications involved, is the ultimate purpose of the mprotect hook to
> > disable dynamic code loading?

> No, it's to provide line of sight to enforcing granular LSM checks
> on enclave pages.  Jumping back to the RWX thing, as a defense in
> depth measure, a policy owner could set an SELinux policy to never
> allow RWX, even for enclaves that dynamically load code.
>
> Whether or not having per-page granluarity on enclave permission
> checks is valuable/interesting is debatable, e.g. it's why LSM
> integration is notably absent from the this series.  But, adding the
> ->mprotect() hook is relatively cheap and can always be removed if
> it's deemed unnecessary in the long run.  The reverse is not true;
> omitting ->mprotect() commits the kernel to an ABI that is either
> ugly and potentially painful (require all enclaves to declare full
> RWX permissions), or flat out prevents adding granular LSM support
> in the future (do nothing).

I believe your analysis with respect to the ability to remove
->mprotect is flawed.  The long standing consensus has been that
functionality never gets broken.  Once ->mprotect is a component of
the ABI it would have to be left intact since it could potentially
break things that elected to use it.  On the other hand there is a
long standing history of adding functionality.

I can't bring myself to believe that LSM's are going to be written
that will be making enclave security decisions on a page by page
basis.  Given what I have written above, I think all of this comes
down to giving platform administrators one of three decisions, in
order of most to least secure:

1.) Block dynamic code loading and execution.

2.) Block access to RWX pages.

3.) The wild west - no restrictions on enclave page protection manipulation.

From a security perspective I would argue for the wisdom of making
option 1 unconditional via a kernel command-line parameter.

It may be that ->mprotect is the right mechanism to implement this.
If that is the case, frame the discussion and documentation so that it
reflects the actual security threat and the consideration and means
for dealing with it.

Hopefully all of this is useful to the stakeholders in this
technology.

Have a good weekend.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 19th Ave. N.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Politics is the business of getting power and privilege without possessing
 merit."
                                -- P.J. O'Rourke

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
  2020-10-24 14:37                                                             ` Dr. Greg
@ 2020-10-24 15:33                                                               ` Andy Lutomirski
  0 siblings, 0 replies; 180+ messages in thread
From: Andy Lutomirski @ 2020-10-24 15:33 UTC (permalink / raw)
  To: Dr. Greg
  Cc: Sean Christopherson, Dave Hansen, Jarkko Sakkinen, Haitao Huang,
	Andy Lutomirski, X86 ML, linux-sgx, LKML, Linux-MM,
	Andrew Morton, Matthew Wilcox, Jethro Beekman, Darren Kenny,
	Andy Shevchenko, asapek, Borislav Petkov, Xing, Cedric,
	chenalexchen, Conrad Parker, cyhanish, Huang, Haitao,
	Josh Triplett, Huang, Kai, Svahn, Kai, Keith Moyer,
	Christian Ludloff, Neil Horman, Nathaniel McCallum,
	Patrick Uiterwijk, David Rientjes, Thomas Gleixner, yaozhangx



> On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote:
> 

> 
> I can't bring myself to believe that LSM's are going to be written
> that will be making enclave security decisions on a page by page
> basis.  Given what I have written above, I think all of this comes
> down to giving platform administrators one of three decisions, in
> order of most to least secure:
> 
> 1.) Block dynamic code loading and execution.
> 

I don’t understand what you’re trying to say. Unless we’re going to split enclaves into multiple VMAs with different permissions, how do you expect to block dynamic code loading unless you have separate RW and RX pages?  That would be “page-by-page”, right?

> 2.) Block access to RWX pages.
> 
> 3.) The wild west - no restrictions on enclave page protection manipulation.
> 
> From a security perspective I would argue for the wisdom of making
> option 1 unconditional via a kernel command-line parameter.
> 
> It may be that ->mprotect is the right mechanism to implement this.
> If that is the case, frame the discussion and documentation so that it
> reflects the actual security threat and the consideration and means
> for dealing with it.
> 
> Hopefully all of this is useful to the stakeholders in this
> technology.
> 
> Have a good weekend.
> 
> Dr. Greg
> 
> As always,
> Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
> Enjellic Systems Development, LLC     IOT platforms and edge devices.
> 4206 19th Ave. N.
> Fargo, ND  58102
> PH: 701-281-1686                      EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Politics is the business of getting power and privilege without possessing
> merit."
>                                -- P.J. O'Rourke

^ permalink raw reply	[flat|nested] 180+ messages in thread

* Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-15 11:05 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
@ 2020-09-28  1:32   ` Jarkko Sakkinen
  0 siblings, 0 replies; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-28  1:32 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, akpm, andriy.shevchenko, asapek, bp,
	chenalexchen, conradparker, cyhanish, dave.hansen, haitao.huang,
	josh, kai.huang, kai.svahn, kmoy, ludloff, luto, nhorman,
	npmccallum, puiterwijk, rientjes, tglx, yaozhangx

On Tue, Sep 15, 2020 at 02:05:19PM +0300, Jarkko Sakkinen wrote:
> +struct sgx_enclave_run {
> +	__u64 tcs;
> +	__u32 flags;
> +	__u32 exit_reason;
> +
> +	union {
> +		sgx_enclave_exit_handler_t user_handler;
> +		__u64 __user_handler;
> +	};

I will replace this with just:

	__u64 user_handler;

> +	__u64 user_data;
> +
> +	union {
> +		struct sgx_enclave_exception exception;
> +
> +		/* Pad the entire struct to 256 bytes. */
> +		__u8 pad[256 - 32];
> +	};
> +};

Resulting:


struct sgx_enclave_run {
	__u64 tcs;
	__u32 flags;
	__u32 exit_reason;
	__u64 user_handler;
	__u64 user_data;

	union {
		struct sgx_enclave_exception exception;

		/* Pad the entire struct to 256 bytes. */
		__u8 pad[256 - 32];
	};
};

BTW, why there is that padding?

/Jarkko

^ permalink raw reply	[flat|nested] 180+ messages in thread

* [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
  2020-09-15 11:04 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
@ 2020-09-15 11:05 ` Jarkko Sakkinen
  2020-09-28  1:32   ` Jarkko Sakkinen
  0 siblings, 1 reply; 180+ messages in thread
From: Jarkko Sakkinen @ 2020-09-15 11:05 UTC (permalink / raw)
  To: x86, linux-sgx
  Cc: linux-kernel, Sean Christopherson, Andy Lutomirski,
	Jethro Beekman, Cedric Xing, Jarkko Sakkinen, akpm,
	andriy.shevchenko, asapek, bp, chenalexchen, conradparker,
	cyhanish, dave.hansen, haitao.huang, josh, kai.huang, kai.svahn,
	kmoy, ludloff, luto, nhorman, npmccallum, puiterwijk, rientjes,
	tglx, yaozhangx

From: Sean Christopherson <sean.j.christopherson@intel.com>

An SGX runtime must be aware of the exceptions, which happen inside an
enclave. Introduce a vDSO call that wraps EENTER/ERESUME cycle and returns
the CPU exception back to the caller exactly when it happens.

Kernel fixups the exception information to RDI, RSI and RDX. The SGX call
vDSO handler fills this information to the user provided buffer or
alternatively trigger user provided callback at the time of the exception.

The calling convention is custom and does not follow System V x86-64 ABI.

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Tested-by: Jethro Beekman <jethro@fortanix.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Cedric Xing <cedric.xing@intel.com>
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/entry/vdso/Makefile             |   2 +
 arch/x86/entry/vdso/vdso.lds.S           |   1 +
 arch/x86/entry/vdso/vsgx_enter_enclave.S | 157 +++++++++++++++++++++++
 arch/x86/include/asm/enclu.h             |   8 ++
 arch/x86/include/uapi/asm/sgx.h          | 128 ++++++++++++++++++
 5 files changed, 296 insertions(+)
 create mode 100644 arch/x86/entry/vdso/vsgx_enter_enclave.S
 create mode 100644 arch/x86/include/asm/enclu.h

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 3f183d0b8826..416f9432269d 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -29,6 +29,7 @@ VDSO32-$(CONFIG_IA32_EMULATION)	:= y
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
 vobjs32-y := vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
 vobjs32-y += vdso32/vclock_gettime.o
+vobjs-$(VDSO64-y)		+= vsgx_enter_enclave.o
 
 # files to link into kernel
 obj-y				+= vma.o extable.o
@@ -100,6 +101,7 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS
 CFLAGS_REMOVE_vclock_gettime.o = -pg
 CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg
 CFLAGS_REMOVE_vgetcpu.o = -pg
+CFLAGS_REMOVE_vsgx_enter_enclave.o = -pg
 
 #
 # X32 processes use x32 vDSO to access 64bit kernel data.
diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
index 36b644e16272..4bf48462fca7 100644
--- a/arch/x86/entry/vdso/vdso.lds.S
+++ b/arch/x86/entry/vdso/vdso.lds.S
@@ -27,6 +27,7 @@ VERSION {
 		__vdso_time;
 		clock_getres;
 		__vdso_clock_getres;
+		__vdso_sgx_enter_enclave;
 	local: *;
 	};
 }
diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
new file mode 100644
index 000000000000..adbd59d41517
--- /dev/null
+++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <linux/linkage.h>
+#include <asm/export.h>
+#include <asm/errno.h>
+#include <asm/enclu.h>
+
+#include "extable.h"
+
+/* Offset of 'struct sgx_enclave_run' relative to %rbp. */
+#define SGX_ENCLAVE_RUN_PTR	2*8
+
+/* Offsets into 'struct sgx_enclave_run'. */
+#define SGX_ENCLAVE_RUN_TSC		0*8
+#define SGX_ENCLAVE_RUN_FLAGS		1*8
+#define SGX_ENCLAVE_RUN_EXIT_REASON	1*8 + 4
+#define SGX_ENCLAVE_RUN_USER_HANDLER	2*8
+/* #define SGX_ENCLAVE_RUN_USER_DATA	3*8 */
+#define SGX_ENCLAVE_RUN_EXCEPTION	4*8
+
+#define SGX_SYNCHRONOUS_EXIT		0
+#define SGX_EXCEPTION_EXIT		1
+
+/* Offsets into sgx_enter_enclave.exception. */
+#define SGX_EX_LEAF			0*8
+#define SGX_EX_TRAPNR			0*8+4
+#define SGX_EX_ERROR_CODE		0*8+6
+#define SGX_EX_ADDRESS			1*8
+
+.code64
+.section .text, "ax"
+
+SYM_FUNC_START(__vdso_sgx_enter_enclave)
+	/* Prolog */
+	.cfi_startproc
+	push	%rbp
+	.cfi_adjust_cfa_offset	8
+	.cfi_rel_offset		%rbp, 0
+	mov	%rsp, %rbp
+	.cfi_def_cfa_register	%rbp
+	push	%rbx
+	.cfi_rel_offset		%rbx, -8
+
+	mov	%ecx, %eax
+.Lenter_enclave:
+	/* EENTER <= leaf <= ERESUME */
+	cmp	$EENTER, %eax
+	jb	.Linvalid_input
+	cmp	$ERESUME, %eax
+	ja	.Linvalid_input
+
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rcx
+
+	/* No flags are currently defined/supported. */
+	cmpl	$0, SGX_ENCLAVE_RUN_FLAGS(%rcx)
+	jne	.Linvalid_input
+
+	/* Load TCS and AEP */
+	mov	SGX_ENCLAVE_RUN_TSC(%rcx), %rbx
+	lea	.Lasync_exit_pointer(%rip), %rcx
+
+	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
+.Lasync_exit_pointer:
+.Lenclu_eenter_eresume:
+	enclu
+
+	/* EEXIT jumps here unless the enclave is doing something fancy. */
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
+
+	/* Set exit_reason. */
+	movl	$SGX_SYNCHRONOUS_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
+
+	/* Invoke userspace's exit handler if one was provided. */
+.Lhandle_exit:
+	cmpq	$0, SGX_ENCLAVE_RUN_USER_HANDLER(%rbx)
+	jne	.Linvoke_userspace_handler
+
+	/* Success, in the sense that ENCLU was attempted. */
+	xor	%eax, %eax
+
+.Lout:
+	pop	%rbx
+	leave
+	.cfi_def_cfa		%rsp, 8
+	ret
+
+	/* The out-of-line code runs with the pre-leave stack frame. */
+	.cfi_def_cfa		%rbp, 16
+
+.Linvalid_input:
+	mov	$(-EINVAL), %eax
+	jmp	.Lout
+
+.Lhandle_exception:
+	mov	SGX_ENCLAVE_RUN_PTR(%rbp), %rbx
+
+	/* Set the exit_reason and exception info. */
+	movl	$SGX_EXCEPTION_EXIT, SGX_ENCLAVE_RUN_EXIT_REASON(%rbx)
+
+	mov	%eax, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_LEAF)(%rbx)
+	mov	%di,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_TRAPNR)(%rbx)
+	mov	%si,  (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ERROR_CODE)(%rbx)
+	mov	%rdx, (SGX_ENCLAVE_RUN_EXCEPTION + SGX_EX_ADDRESS)(%rbx)
+	jmp	.Lhandle_exit
+
+.Linvoke_userspace_handler:
+	/* Pass the untrusted RSP (at exit) to the callback via %rcx. */
+	mov	%rsp, %rcx
+
+	/* Save @e, %rbx is about to be clobbered. */
+	mov	%rbx, %rax
+
+	/* Save the untrusted RSP offset in %rbx (non-volatile register). */
+	mov	%rsp, %rbx
+	and	$0xf, %rbx
+
+	/*
+	 * Align stack per x86_64 ABI. Note, %rsp needs to be 16-byte aligned
+	 * _after_ pushing the parameters on the stack, hence the bonus push.
+	 */
+	and	$-0x10, %rsp
+	push	%rax
+
+	/* Push @e as a param to the callback. */
+	push	%rax
+
+	/* Clear RFLAGS.DF per x86_64 ABI */
+	cld
+
+	/* Load the callback pointer to %rax and invoke it via retpoline. */
+	mov	SGX_ENCLAVE_RUN_USER_HANDLER(%rax), %rax
+	call	.Lretpoline
+
+	/* Undo the post-exit %rsp adjustment. */
+	lea	0x10(%rsp, %rbx), %rsp
+
+	/*
+	 * If the return from callback is zero or negative, return immediately,
+	 * else re-execute ENCLU with the postive return value interpreted as
+	 * the requested ENCLU leaf.
+	 */
+	cmp	$0, %eax
+	jle	.Lout
+	jmp	.Lenter_enclave
+
+.Lretpoline:
+	call	2f
+1:	pause
+	lfence
+	jmp	1b
+2:	mov	%rax, (%rsp)
+	ret
+	.cfi_endproc
+
+_ASM_VDSO_EXTABLE_HANDLE(.Lenclu_eenter_eresume, .Lhandle_exception)
+
+SYM_FUNC_END(__vdso_sgx_enter_enclave)
diff --git a/arch/x86/include/asm/enclu.h b/arch/x86/include/asm/enclu.h
new file mode 100644
index 000000000000..06157b3e9ede
--- /dev/null
+++ b/arch/x86/include/asm/enclu.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ENCLU_H
+#define _ASM_X86_ENCLU_H
+
+#define EENTER	0x02
+#define ERESUME	0x03
+
+#endif /* _ASM_X86_ENCLU_H */
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index d0916fb9629e..1564d7f88597 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -72,4 +72,132 @@ struct sgx_enclave_provision {
 	__u64 attribute_fd;
 };
 
+#define SGX_SYNCHRONOUS_EXIT	0
+#define SGX_EXCEPTION_EXIT	1
+
+struct sgx_enclave_run;
+
+/**
+ * typedef sgx_enclave_exit_handler_t - Exit handler function accepted by
+ *					__vdso_sgx_enter_enclave()
+ *
+ * @rdi:	RDI at the time of enclave exit
+ * @rsi:	RSI at the time of enclave exit
+ * @rdx:	RDX at the time of enclave exit
+ * @ursp:	RSP at the time of enclave exit (untrusted stack)
+ * @r8:		R8 at the time of enclave exit
+ * @r9:		R9 at the time of enclave exit
+ * @r:		Pointer to struct sgx_enclave_run (as provided by caller)
+ *
+ * Return:
+ *  0 or negative to exit vDSO
+ *  positive to re-enter enclave (must be EENTER or ERESUME leaf)
+ */
+typedef int (*sgx_enclave_exit_handler_t)(long rdi, long rsi, long rdx,
+					  long ursp, long r8, long r9,
+					  struct sgx_enclave_run *r);
+
+/**
+ * struct sgx_enclave_exception - structure to report exceptions encountered in
+ *				  __vdso_sgx_enter_enclave()
+ *
+ * @leaf:	ENCLU leaf from \%eax at time of exception
+ * @trapnr:	exception trap number, a.k.a. fault vector
+ * @error_code:	exception error code
+ * @address:	exception address, e.g. CR2 on a #PF
+ */
+struct sgx_enclave_exception {
+	__u32 leaf;
+	__u16 trapnr;
+	__u16 error_code;
+	__u64 address;
+};
+
+/**
+ * struct sgx_enclave_run - Control structure for __vdso_sgx_enter_enclave()
+ *
+ * @tcs:		Thread Control Structure used to enter enclave
+ * @flags:		Control flags
+ * @exit_reason:	Cause of exit from enclave, e.g. EEXIT vs. exception
+ * @user_handler:	User provided exit handler (optional)
+ * @user_data:		User provided opaque value (optional)
+ * @exception:		Valid on exit due to exception
+ */
+struct sgx_enclave_run {
+	__u64 tcs;
+	__u32 flags;
+	__u32 exit_reason;
+
+	union {
+		sgx_enclave_exit_handler_t user_handler;
+		__u64 __user_handler;
+	};
+	__u64 user_data;
+
+	union {
+		struct sgx_enclave_exception exception;
+
+		/* Pad the entire struct to 256 bytes. */
+		__u8 pad[256 - 32];
+	};
+};
+
+/**
+ * typedef vdso_sgx_enter_enclave_t - Prototype for __vdso_sgx_enter_enclave(),
+ *				      a vDSO function to enter an SGX enclave.
+ *
+ * @rdi:	Pass-through value for RDI
+ * @rsi:	Pass-through value for RSI
+ * @rdx:	Pass-through value for RDX
+ * @leaf:	ENCLU leaf, must be EENTER or ERESUME
+ * @r8:		Pass-through value for R8
+ * @r9:		Pass-through value for R9
+ * @r:		struct sgx_enclave_run, must be non-NULL
+ *
+ * NOTE: __vdso_sgx_enter_enclave() does not ensure full compliance with the
+ * x86-64 ABI, e.g. doesn't handle XSAVE state.  Except for non-volatile
+ * general purpose registers, EFLAGS.DF, and RSP alignment, preserving/setting
+ * state in accordance with the x86-64 ABI is the responsibility of the enclave
+ * and its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C
+ * code without careful consideration by both the enclave and its runtime.
+ *
+ * All general purpose registers except RAX, RBX and RCX are passed as-is to
+ * the enclave.  RAX, RBX and RCX are consumed by EENTER and ERESUME and are
+ * loaded with @leaf, asynchronous exit pointer, and @tcs respectively.
+ *
+ * RBP and the stack are used to anchor __vdso_sgx_enter_enclave() to the
+ * pre-enclave state, e.g. to retrieve @e and @handler after an enclave exit.
+ * All other registers are available for use by the enclave and its runtime,
+ * e.g. an enclave can push additional data onto the stack (and modify RSP) to
+ * pass information to the optional exit handler (see below).
+ *
+ * Most exceptions reported on ENCLU, including those that occur within the
+ * enclave, are fixed up and reported synchronously instead of being delivered
+ * via a standard signal. Debug Exceptions (#DB) and Breakpoints (#BP) are
+ * never fixed up and are always delivered via standard signals. On synchrously
+ * reported exceptions, -EFAULT is returned and details about the exception are
+ * recorded in @e, the optional sgx_enclave_exception struct.
+ *
+ * If an exit handler is provided, the handler will be invoked on synchronous
+ * exits from the enclave and for all synchronously reported exceptions. In
+ * latter case, @e is filled prior to invoking the handler.
+ *
+ * The exit handler's return value is interpreted as follows:
+ *  >0:		continue, restart __vdso_sgx_enter_enclave() with @ret as @leaf
+ *   0:		success, return @ret to the caller
+ *  <0:		error, return @ret to the caller
+ *
+ * The exit handler may transfer control, e.g. via longjmp() or C++ exception,
+ * without returning to __vdso_sgx_enter_enclave().
+ *
+ * Return:
+ *  0 on success (ENCLU reached),
+ *  -EINVAL if ENCLU leaf is not allowed,
+ *  -errno for all other negative values returned by the userspace exit handler
+ */
+typedef int (*vdso_sgx_enter_enclave_t)(unsigned long rdi, unsigned long rsi,
+					unsigned long rdx, unsigned int leaf,
+					unsigned long r8,  unsigned long r9,
+					struct sgx_enclave_run *r);
+
 #endif /* _UAPI_ASM_X86_SGX_H */
-- 
2.25.1


^ permalink raw reply	[flat|nested] 180+ messages in thread

end of thread, back to index

Thread overview: 180+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-15 11:28 [PATCH v38 00/24] Intel SGX foundations Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2020-09-16 11:44   ` Borislav Petkov
2020-09-16 20:30     ` Jarkko Sakkinen
2020-09-16 20:32       ` Borislav Petkov
2020-09-15 11:28 ` [PATCH v38 04/24] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 05/24] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 06/24] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 07/24] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 08/24] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 09/24] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
2020-09-18 12:44   ` Borislav Petkov
2020-09-18 15:09   ` Andy Lutomirski
2020-09-18 23:24     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect()' Jarkko Sakkinen
2020-09-18 23:53     ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Sean Christopherson
2020-09-19  0:15       ` Andy Lutomirski
     [not found]         ` <20200922125801.GA133710@linux.intel.com>
2020-09-22 15:11           ` Dave Hansen
2020-09-23 13:30             ` Jarkko Sakkinen
2020-09-23 13:43             ` Jarkko Sakkinen
2020-09-23 14:33             ` Jarkko Sakkinen
2020-09-24 14:50               ` Dave Hansen
2020-09-24 16:27                 ` Sean Christopherson
     [not found]       ` <20200921124946.GF6038@linux.intel.com>
2020-09-21 12:51         ` Jarkko Sakkinen
2020-09-21 13:14         ` Jarkko Sakkinen
     [not found]         ` <20200921165758.GA24156@linux.intel.com>
2020-09-21 21:07           ` Jarkko Sakkinen
2020-09-21 21:18             ` Sean Christopherson
2020-09-22  5:29               ` Jarkko Sakkinen
2020-09-22  5:35                 ` Jarkko Sakkinen
2020-09-22 16:43                   ` Sean Christopherson
2020-09-23 13:50                     ` Jarkko Sakkinen
2020-09-24 19:11                       ` Haitao Huang
2020-09-24 19:28                         ` Sean Christopherson
2020-09-24 19:39                           ` Dave Hansen
2020-09-24 20:01                             ` Sean Christopherson
2020-09-24 20:10                               ` Dave Hansen
2020-09-24 20:25                                 ` Sean Christopherson
2020-09-24 20:54                                   ` Dave Hansen
2020-09-24 23:05                                     ` Sean Christopherson
2020-09-24 23:09                                       ` Dave Hansen
2020-09-25  0:00                                         ` Sean Christopherson
2020-09-25 17:18                                           ` Dave Hansen
2020-09-25 19:43                                             ` Sean Christopherson
2020-09-25 19:53                                               ` Dave Hansen
2020-09-26  4:15                                                 ` Andy Lutomirski
2020-09-28  0:53                                                 ` Jarkko Sakkinen
2020-09-28 14:04                                                   ` Dave Hansen
2020-09-28 16:19                                                     ` Jarkko Sakkinen
2020-09-28 16:48                                                       ` Dave Hansen
2020-09-28 19:32                                                         ` Jarkko Sakkinen
2020-09-28 19:45                                                           ` Dave Hansen
2020-09-28 20:19                                                             ` Jarkko Sakkinen
2020-09-29  1:37                                                               ` Andy Lutomirski
2020-09-29  4:05                                                                 ` Jarkko Sakkinen
2020-09-29 14:24                                                                   ` Dave Hansen
2020-09-30  0:20                                                                     ` Jarkko Sakkinen
2020-09-30 14:35                                                                       ` Dave Hansen
2020-09-28 20:18                                                         ` Jarkko Sakkinen
2020-10-18  8:49                                                     ` Dr. Greg
2020-10-19 21:31                                                       ` Sean Christopherson
2020-10-20 10:01                                                         ` Dr. Greg
2020-10-20 16:40                                                           ` Sean Christopherson
2020-10-24 14:37                                                             ` Dr. Greg
2020-10-24 15:33                                                               ` Andy Lutomirski
2020-09-24 22:07                                 ` Jarkko Sakkinen
2020-09-24 21:58                           ` Jarkko Sakkinen
2020-09-24 21:55                         ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
2020-09-21  9:30   ` Borislav Petkov
2020-09-21 12:09     ` Jarkko Sakkinen
2020-10-01 17:36   ` Sean Christopherson
2020-10-01 18:49     ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
2020-09-21 10:03   ` Borislav Petkov
2020-09-21 12:28     ` Jarkko Sakkinen
2020-09-21 13:51       ` Borislav Petkov
2020-09-21 19:29         ` Jarkko Sakkinen
2020-10-03  0:23   ` Haitao Huang
2020-10-03  3:24     ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT Jarkko Sakkinen
2020-09-21 17:35   ` Borislav Petkov
2020-09-21 18:10     ` Sean Christopherson
2020-09-21 18:27       ` Borislav Petkov
     [not found]         ` <20200921191658.GA24823@linux.intel.com>
2020-09-22  8:29           ` Borislav Petkov
2020-09-22 11:50             ` Jarkko Sakkinen
2020-09-22 12:56             ` Jethro Beekman
2020-09-22 14:29               ` Borislav Petkov
2020-09-23 14:47                 ` Jarkko Sakkinen
2020-09-23 15:55                   ` Borislav Petkov
2020-09-24 12:23                     ` Jarkko Sakkinen
2020-09-22 16:29               ` Sean Christopherson
2020-09-21 19:22       ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation Jarkko Sakkinen
2020-09-21 18:07   ` Borislav Petkov
2020-09-21 19:27     ` Jarkko Sakkinen
2020-09-21 19:41       ` Borislav Petkov
2020-09-21 21:26         ` Jarkko Sakkinen
2020-09-22  8:30           ` Borislav Petkov
2020-09-15 11:28 ` [PATCH v38 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-09-22 10:45   ` Borislav Petkov
2020-09-22 14:03     ` Jarkko Sakkinen
2020-09-22 14:24       ` Borislav Petkov
2020-09-23 14:52         ` Jarkko Sakkinen
2020-09-29  1:14       ` Sean Christopherson
2020-09-29  3:50         ` Jarkko Sakkinen
2020-09-29  8:35           ` Sean Christopherson
2020-09-22 16:24     ` Sean Christopherson
2020-09-22 18:02       ` Borislav Petkov
2020-09-23 15:25       ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2020-09-22 15:44   ` Borislav Petkov
2020-09-23 13:20     ` Jarkko Sakkinen
2020-09-23 16:17       ` Borislav Petkov
2020-09-24 11:51         ` Jarkko Sakkinen
2020-09-24 15:57           ` Borislav Petkov
2020-09-24 20:38             ` [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver' Jarkko Sakkinen
2020-09-24 20:40               ` Jarkko Sakkinen
2020-09-25  7:53                 ` Borislav Petkov
2020-09-25 11:00                   ` Jarkko Sakkinen
2020-09-25  7:51               ` Borislav Petkov
2020-09-25 11:21                 ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-09-23 22:07   ` Borislav Petkov
2020-09-24 12:09     ` Jarkko Sakkinen
2020-09-24 16:00       ` Borislav Petkov
2020-09-24 21:07         ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 19/24] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-09-24 16:31   ` Borislav Petkov
2020-09-24 23:11     ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
2020-09-24 18:04   ` Borislav Petkov
2020-09-25  1:00     ` Jarkko Sakkinen
2020-09-25  8:28       ` Borislav Petkov
2020-09-27 23:37         ` Jarkko Sakkinen
2020-09-28  8:30           ` Borislav Petkov
2020-09-28 15:02             ` Jarkko Sakkinen
2020-09-25  8:39       ` Jethro Beekman
2020-09-25 11:17         ` Jarkko Sakkinen
2020-09-25 11:43           ` Jethro Beekman
     [not found]     ` <20200925003808.GB20333@linux.intel.com>
2020-09-25  1:04       ` Jarkko Sakkinen
2020-09-25  8:14       ` Borislav Petkov
2020-09-25 10:59         ` Jarkko Sakkinen
2020-09-28 14:36       ` Jarkko Sakkinen
2020-09-25 18:23   ` Andrew Cooper
2020-09-28  0:58     ` Jarkko Sakkinen
2020-09-28 16:44       ` Andrew Cooper
2020-09-28 18:07         ` H.J. Lu
2020-09-28 18:12           ` Andy Lutomirski
2020-09-28 18:17             ` Dave Hansen
2020-09-28 22:07               ` Jarkko Sakkinen
2020-09-28 21:56             ` Jarkko Sakkinen
2020-09-28 22:06               ` H.J. Lu
2020-09-28 22:18                 ` Dave Hansen
2020-09-28 22:41                   ` Andy Lutomirski
2020-09-28 23:38                     ` A