linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v6 00/11] Intel SGX Driver
@ 2017-11-25 19:29 Jarkko Sakkinen
  2017-11-25 19:29 ` [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
                   ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-11-25 19:29 UTC (permalink / raw)
  To: platform-driver-x86, x86
  Cc: linux-kernel, Jarkko Sakkinen, Borislav Petkov, David S. Miller,
	Greg Kroah-Hartman, Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

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.
In a way you can think that SGX provides inverted sandbox. It protects the
application from a malicious host.

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.

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

	cat /proc/cpuinfo  | grep sgx

The GIT repositoy for SGX driver resides in

	https://github.com/jsakkine-intel/linux-sgx.git

'le' branch contains the upstream candidate patches.

'master' branch contains the same patches with the following differences:

* top-level patch modifies the ioctl API to be SDK compatible
* does not use flexible launch control but instead relies on SDK provided
  Intel launch enclave.

Backlog:
* AES: how to use arch/x86/crypto/aesni-intel_asm.S from the enclave. I
  guess these routines should be fairly easy to call directly (haven't
  investigated deeply). Any advice is appreciated.
* Layout: what and where to place in arch/x86.
* MAINTAINERS: who to add as reviewer.

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()


Haim Cohen (1):
  x86: add SGX MSRs to msr-index.h

Jarkko Sakkinen (8):
  intel_sgx: updated MAINTAINERS
  x86: define IA32_FEATUE_CONTROL.SGX_LC
  intel_sgx: driver for Intel Software Guard Extensions
  intel_sgx: ptrace() support
  intel_sgx: in-kernel launch enclave
  fs/pipe.c: export create_pipe_files() and replace_fd()
  intel_sgx: glue code for in-kernel LE
  intel_sgx: driver documentation

Kai Huang (1):
  x86: add SGX definition to cpufeature

Sean Christopherson (1):
  x86: define IA32_FEATURE_CONTROL.SGX_ENABLE

 Documentation/index.rst                            |   1 +
 Documentation/x86/intel_sgx.rst                    | 101 +++
 MAINTAINERS                                        |   5 +
 arch/x86/include/asm/cpufeatures.h                 |   2 +
 arch/x86/include/asm/msr-index.h                   |   8 +
 arch/x86/include/asm/sgx.h                         | 233 +++++
 arch/x86/include/asm/sgx_arch.h                    | 268 ++++++
 arch/x86/include/uapi/asm/sgx.h                    | 138 +++
 drivers/platform/x86/Kconfig                       |   2 +
 drivers/platform/x86/Makefile                      |   1 +
 drivers/platform/x86/intel_sgx/Kconfig             |  34 +
 drivers/platform/x86/intel_sgx/Makefile            |  32 +
 drivers/platform/x86/intel_sgx/le/Makefile         |  26 +
 drivers/platform/x86/intel_sgx/le/enclave/Makefile |  46 +
 .../x86/intel_sgx/le/enclave/aes_encrypt.c         | 191 ++++
 .../platform/x86/intel_sgx/le/enclave/cmac_mode.c  | 254 ++++++
 .../x86/intel_sgx/le/enclave/encl_bootstrap.S      | 163 ++++
 .../intel_sgx/le/enclave/include/tinycrypt/aes.h   | 133 +++
 .../le/enclave/include/tinycrypt/cmac_mode.h       | 194 ++++
 .../le/enclave/include/tinycrypt/constants.h       |  59 ++
 .../intel_sgx/le/enclave/include/tinycrypt/utils.h |  95 ++
 drivers/platform/x86/intel_sgx/le/enclave/main.c   | 203 +++++
 .../platform/x86/intel_sgx/le/enclave/sgx_le.lds   |  28 +
 .../platform/x86/intel_sgx/le/enclave/sgxsign.c    | 538 +++++++++++
 drivers/platform/x86/intel_sgx/le/enclave/utils.c  |  78 ++
 drivers/platform/x86/intel_sgx/le/entry.S          | 117 +++
 .../platform/x86/intel_sgx/le/include/sgx_asm.h    |  64 ++
 .../platform/x86/intel_sgx/le/include/sgx_encl.h   | 110 +++
 drivers/platform/x86/intel_sgx/le/main.c           | 214 +++++
 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S   |  15 +
 drivers/platform/x86/intel_sgx/sgx.h               | 268 ++++++
 drivers/platform/x86/intel_sgx/sgx_encl.c          | 999 +++++++++++++++++++++
 drivers/platform/x86/intel_sgx/sgx_ioctl.c         | 282 ++++++
 drivers/platform/x86/intel_sgx/sgx_le.c            | 319 +++++++
 .../platform/x86/intel_sgx/sgx_le_proxy_piggy.S    |  15 +
 drivers/platform/x86/intel_sgx/sgx_main.c          | 456 ++++++++++
 drivers/platform/x86/intel_sgx/sgx_page_cache.c    | 619 +++++++++++++
 drivers/platform/x86/intel_sgx/sgx_util.c          | 394 ++++++++
 drivers/platform/x86/intel_sgx/sgx_vma.c           | 236 +++++
 fs/file.c                                          |   1 +
 fs/pipe.c                                          |   1 +
 41 files changed, 6943 insertions(+)
 create mode 100644 Documentation/x86/intel_sgx.rst
 create mode 100644 arch/x86/include/asm/sgx.h
 create mode 100644 arch/x86/include/asm/sgx_arch.h
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
 create mode 100644 drivers/platform/x86/intel_sgx/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/aes_encrypt.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/encl_bootstrap.S
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/aes.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/cmac_mode.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/constants.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/utils.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgx_le.lds
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgxsign.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/utils.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/entry.S
 create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_asm.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_encl.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
 create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c

-- 
2.14.1

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

* [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-25 19:29 [PATCH v6 00/11] Intel SGX Driver Jarkko Sakkinen
@ 2017-11-25 19:29 ` Jarkko Sakkinen
  2017-11-28 14:35   ` Christoph Hellwig
  2017-12-12 14:07 ` [PATCH v6 00/11] Intel SGX Driver Pavel Machek
  2018-01-04 14:17 ` Cedric Blancher
  2 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-11-25 19:29 UTC (permalink / raw)
  To: platform-driver-x86, x86
  Cc: linux-kernel, Jarkko Sakkinen, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

Exported create_pipe_files() and replace_fd() because the SGX driver
needs to be able to setup pipes in order to communicate with the helper
process that hosts the Launch Enclave (LE). The pipe creation will be
done in the init-callback supplied to call_usermodehelper_setup().

The driver will use two pipes for communication with the LE hosting
process:

* One for writing SIGSTRUCT blobs.
* One for reading EINITTOKEN blobs.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 fs/file.c | 1 +
 fs/pipe.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/file.c b/fs/file.c
index 1fc7fbbb4510..b1fa28919b22 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -871,6 +871,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags)
 	spin_unlock(&files->file_lock);
 	return err;
 }
+EXPORT_SYMBOL_GPL(replace_fd);
 
 SYSCALL_DEFINE3(dup3, unsigned int, oldfd, unsigned int, newfd, int, flags)
 {
diff --git a/fs/pipe.c b/fs/pipe.c
index 97e5be897753..ee33a84127e7 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -784,6 +784,7 @@ int create_pipe_files(struct file **res, int flags)
 	iput(inode);
 	return err;
 }
+EXPORT_SYMBOL_GPL(create_pipe_files);
 
 static int __do_pipe_flags(int *fd, struct file **files, int flags)
 {
-- 
2.14.1

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-25 19:29 ` [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
@ 2017-11-28 14:35   ` Christoph Hellwig
  2017-11-28 20:42     ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2017-11-28 14:35 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: platform-driver-x86, x86, linux-kernel, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

Repeated NAK - any interface that deals with raw file descriptor table
entries has absolutely no business in a driver.

Please fix your API already.

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-28 14:35   ` Christoph Hellwig
@ 2017-11-28 20:42     ` Jarkko Sakkinen
  2017-11-28 21:05       ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-11-28 20:42 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: platform-driver-x86, x86, linux-kernel, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

On Tue, Nov 28, 2017 at 06:35:04AM -0800, Christoph Hellwig wrote:
> Repeated NAK - any interface that deals with raw file descriptor table
> entries has absolutely no business in a driver.
> 
> Please fix your API already.

Does it make a differnece if the code is moved to arch/x86, which could
potentially happen (see Darren's and tglx's comments on v5)? Then the
need for export will be gone.

/Jarkko

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-28 20:42     ` Jarkko Sakkinen
@ 2017-11-28 21:05       ` Christoph Hellwig
  2017-11-28 21:57         ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2017-11-28 21:05 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Christoph Hellwig, platform-driver-x86, x86, linux-kernel,
	Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure)

On Tue, Nov 28, 2017 at 10:42:20PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 28, 2017 at 06:35:04AM -0800, Christoph Hellwig wrote:
> > Repeated NAK - any interface that deals with raw file descriptor table
> > entries has absolutely no business in a driver.
> > 
> > Please fix your API already.
> 
> Does it make a differnece if the code is moved to arch/x86, which could
> potentially happen (see Darren's and tglx's comments on v5)? Then the
> need for export will be gone.

Yes.  You still shall not play nasty games with file descriptors.

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-28 21:05       ` Christoph Hellwig
@ 2017-11-28 21:57         ` Jarkko Sakkinen
  2017-11-29 23:13           ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-11-28 21:57 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: platform-driver-x86, x86, linux-kernel, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

On Tue, Nov 28, 2017 at 01:05:51PM -0800, Christoph Hellwig wrote:
> On Tue, Nov 28, 2017 at 10:42:20PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Nov 28, 2017 at 06:35:04AM -0800, Christoph Hellwig wrote:
> > > Repeated NAK - any interface that deals with raw file descriptor table
> > > entries has absolutely no business in a driver.
> > > 
> > > Please fix your API already.
> > 
> > Does it make a differnece if the code is moved to arch/x86, which could
> > potentially happen (see Darren's and tglx's comments on v5)? Then the
> > need for export will be gone.
> 
> Yes.  You still shall not play nasty games with file descriptors.

I need to put something to file descriptors in order to have a IO
channels for the launch enclave hosting process.

/Jarkko

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-28 21:57         ` Jarkko Sakkinen
@ 2017-11-29 23:13           ` Christoph Hellwig
  2017-11-30 16:43             ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2017-11-29 23:13 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Christoph Hellwig, platform-driver-x86, x86, linux-kernel,
	Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure)

On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > Yes.  You still shall not play nasty games with file descriptors.
> 
> I need to put something to file descriptors in order to have a IO
> channels for the launch enclave hosting process.

Just do it like any other program - open it from your userspace
program using open() and related syscalls.

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-29 23:13           ` Christoph Hellwig
@ 2017-11-30 16:43             ` Jarkko Sakkinen
  2017-11-30 18:38               ` James Bottomley
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-11-30 16:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: platform-driver-x86, x86, linux-kernel, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote:
> On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > > Yes.  You still shall not play nasty games with file descriptors.
> > 
> > I need to put something to file descriptors in order to have a IO
> > channels for the launch enclave hosting process.
> 
> Just do it like any other program - open it from your userspace
> program using open() and related syscalls.

In this case it would not work as the launch enclave is still part of
the kernel and it would create a dependency how the user space defines
paths. If using pipe specifically is an issue, I could easily use shmem
file as a mean for communiation.

The way I implemented is much like how I did arch/x86/realmode with HPA
and it has kind of comparable requirements, part of the kernel but not
exactly code living in the kernel namespace.

/Jarkko

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-30 16:43             ` Jarkko Sakkinen
@ 2017-11-30 18:38               ` James Bottomley
  2017-12-04  9:00                 ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: James Bottomley @ 2017-11-30 18:38 UTC (permalink / raw)
  To: Jarkko Sakkinen, Christoph Hellwig
  Cc: platform-driver-x86, x86, linux-kernel, Alexander Viro,
	open list:FILESYSTEMS (VFS and infrastructure)

On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote:
> > 
> > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > > 
> > > > 
> > > > Yes.  You still shall not play nasty games with file
> > > > descriptors.
> > > 
> > > I need to put something to file descriptors in order to have a IO
> > > channels for the launch enclave hosting process.
> > 
> > Just do it like any other program - open it from your userspace
> > program using open() and related syscalls.
> 
> In this case it would not work as the launch enclave is still part of
> the kernel and it would create a dependency how the user space
> defines paths. If using pipe specifically is an issue, I could easily
> use shmem file as a mean for communiation.

Can't you simply use 

sys_pipe2()
sys_close()
sys_dup2()

To achieve the same effect as replace_fd()/create_pipe_files()?

The point Christoph is making is that you can call sys_ interfaces from
within the kernel (carefully) and have them operate like direct
invocations.  Look at main.c:kernel_init_freeable() it's doing
something similar to what you want, except with the console, not a pipe
and it begins with the file table empty.

James

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-11-30 18:38               ` James Bottomley
@ 2017-12-04  9:00                 ` Jarkko Sakkinen
  2017-12-07 17:37                   ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-04  9:00 UTC (permalink / raw)
  To: James Bottomley
  Cc: Christoph Hellwig, platform-driver-x86, x86, linux-kernel,
	Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure)

On Thu, Nov 30, 2017 at 10:38:30AM -0800, James Bottomley wrote:
> On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote:
> > On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote:
> > > 
> > > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > > > 
> > > > > 
> > > > > Yes.��You still shall not play nasty games with file
> > > > > descriptors.
> > > > 
> > > > I need to put something to file descriptors in order to have a IO
> > > > channels for the launch enclave hosting process.
> > > 
> > > Just do it like any other program - open it from your userspace
> > > program using open() and related syscalls.
> > 
> > In this case it would not work as the launch enclave is still part of
> > the kernel and it would create a dependency how the user space
> > defines paths. If using pipe specifically is an issue, I could easily
> > use shmem file as a mean for communiation.
> 
> Can't you simply use�
> 
> sys_pipe2()
> sys_close()
> sys_dup2()
> 
> To achieve the same effect as replace_fd()/create_pipe_files()?
> 
> The point Christoph is making is that you can call sys_ interfaces from
> within the kernel (carefully) and have them operate like direct
> invocations. �Look at main.c:kernel_init_freeable() it's doing
> something similar to what you want, except with the console, not a pipe
> and it begins with the file table empty.

Thank you. I'll take a peek.

/Jarkko

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-12-04  9:00                 ` Jarkko Sakkinen
@ 2017-12-07 17:37                   ` Jarkko Sakkinen
  2017-12-08 13:05                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-07 17:37 UTC (permalink / raw)
  To: James Bottomley
  Cc: Christoph Hellwig, platform-driver-x86, x86, linux-kernel,
	Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure)

On Mon, Dec 04, 2017 at 11:00:59AM +0200, Jarkko Sakkinen wrote:
> On Thu, Nov 30, 2017 at 10:38:30AM -0800, James Bottomley wrote:
> > On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote:
> > > On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote:
> > > > 
> > > > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote:
> > > > > 
> > > > > > 
> > > > > > Yes.��You still shall not play nasty games with file
> > > > > > descriptors.
> > > > > 
> > > > > I need to put something to file descriptors in order to have a IO
> > > > > channels for the launch enclave hosting process.
> > > > 
> > > > Just do it like any other program - open it from your userspace
> > > > program using open() and related syscalls.
> > > 
> > > In this case it would not work as the launch enclave is still part of
> > > the kernel and it would create a dependency how the user space
> > > defines paths. If using pipe specifically is an issue, I could easily
> > > use shmem file as a mean for communiation.
> > 
> > Can't you simply use�
> > 
> > sys_pipe2()
> > sys_close()
> > sys_dup2()
> > 
> > To achieve the same effect as replace_fd()/create_pipe_files()?
> > 
> > The point Christoph is making is that you can call sys_ interfaces from
> > within the kernel (carefully) and have them operate like direct
> > invocations. �Look at main.c:kernel_init_freeable() it's doing
> > something similar to what you want, except with the console, not a pipe
> > and it begins with the file table empty.
> 
> Thank you. I'll take a peek.

It doesn't apply here as it depends of the filesystem paths.

I think I could replace pipes with anonymous inodes. Is that a better
idea than pipes? I can work on that v8 if the export is a show stopper
as it seems. We are using that to do some other stuff in tpm_vtpm_proxy.

I submitted v7 of the patch set still as a self-contained driver. For
that I'm looking forward to get feedback on:

1. Could the first upstream version be a self-contained driver even if
some stuff would be eventually moved to arch/x86? There is nothing
preventing on doing that and that would be a non-intrusive way to
upstream such a large piece of functionality.
2. If for the first upstream version something needs to be placed to
arch/x86, I would like to get some guidelines on deployment. I guess
it would go under arch/x86/kernel/cpu/sgx?
3. I fixed the AES issue. Is there anything else BIG that needs to be
fixed?

/Jarkko

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

* Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()
  2017-12-07 17:37                   ` Jarkko Sakkinen
@ 2017-12-08 13:05                     ` Jarkko Sakkinen
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-08 13:05 UTC (permalink / raw)
  To: James Bottomley
  Cc: Christoph Hellwig, platform-driver-x86, x86, linux-kernel,
	Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure)

On Thu, Dec 07, 2017 at 07:37:38PM +0200, Jarkko Sakkinen wrote:
> I think I could replace pipes with anonymous inodes. Is that a better
> idea than pipes? I can work on that v8 if the export is a show stopper
> as it seems. We are using that to do some other stuff in tpm_vtpm_proxy.

I'll go with the anon inode solution. It should be fairly easy
to implement.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-11-25 19:29 [PATCH v6 00/11] Intel SGX Driver Jarkko Sakkinen
  2017-11-25 19:29 ` [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
@ 2017-12-12 14:07 ` Pavel Machek
  2017-12-14 11:18   ` Jarkko Sakkinen
  2017-12-19 23:33   ` Jarkko Sakkinen
  2018-01-04 14:17 ` Cedric Blancher
  2 siblings, 2 replies; 31+ messages in thread
From: Pavel Machek @ 2017-12-12 14:07 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: platform-driver-x86, x86, linux-kernel, Borislav Petkov,
	David S. Miller, Greg Kroah-Hartman, Grzegorz Andrejczuk,
	Haim Cohen, Ingo Molnar, Janakarajan Natarajan, Jim Mattson,
	Kan Liang, Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> 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.
> In a way you can think that SGX provides inverted sandbox. It protects the
> application from a malicious host.

Would you list guarantees provided by SGX?

For example, host can still observe timing of cachelines being
accessed by "protected" app, right? Can it also introduce bit flips?

								Pavel

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-12-12 14:07 ` [PATCH v6 00/11] Intel SGX Driver Pavel Machek
@ 2017-12-14 11:18   ` Jarkko Sakkinen
  2017-12-19 23:33   ` Jarkko Sakkinen
  1 sibling, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-14 11:18 UTC (permalink / raw)
  To: Pavel Machek
  Cc: platform-driver-x86, x86, linux-kernel, Borislav Petkov,
	David S. Miller, Greg Kroah-Hartman, Grzegorz Andrejczuk,
	Haim Cohen, Ingo Molnar, Janakarajan Natarajan, Jim Mattson,
	Kan Liang, Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Tue, Dec 12, 2017 at 03:07:50PM +0100, Pavel Machek wrote:
> On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > 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.
> > In a way you can think that SGX provides inverted sandbox. It protects the
> > application from a malicious host.
> 
> Would you list guarantees provided by SGX?
> 
> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?
> 
> 								Pavel

I'll put this in my backlog. Thank you.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-12-12 14:07 ` [PATCH v6 00/11] Intel SGX Driver Pavel Machek
  2017-12-14 11:18   ` Jarkko Sakkinen
@ 2017-12-19 23:33   ` Jarkko Sakkinen
  2017-12-20 13:18     ` Jarkko Sakkinen
  1 sibling, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-19 23:33 UTC (permalink / raw)
  To: Pavel Machek
  Cc: platform-driver-x86, x86, linux-kernel, Borislav Petkov,
	David S. Miller, Greg Kroah-Hartman, Grzegorz Andrejczuk,
	Haim Cohen, Ingo Molnar, Janakarajan Natarajan, Jim Mattson,
	Kan Liang, Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Tue, 2017-12-12 at 15:07 +0100, Pavel Machek wrote:
> On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > 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.
> > In a way you can think that SGX provides inverted sandbox. It protects the
> > application from a malicious host.
> 
> Would you list guarantees provided by SGX?
> 
> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?
> 
> 								Pavel

I'll give a more proper response to this now that all the reported major
issues in the code have been fixed in v9.

Yes, SGX is vulnerable to the L1 cacheline timing attacks. Jethro
Beekman wrote a great summary about this on early March:

  https://jbeekman.nl/blog/2017/03/sgx-side-channel-attacks/

The counter measures are the same as without SGX. It really does not
add or degrade security in this area.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-12-19 23:33   ` Jarkko Sakkinen
@ 2017-12-20 13:18     ` Jarkko Sakkinen
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2017-12-20 13:18 UTC (permalink / raw)
  To: Pavel Machek
  Cc: platform-driver-x86, x86, linux-kernel, Borislav Petkov,
	David S. Miller, Greg Kroah-Hartman, Grzegorz Andrejczuk,
	Haim Cohen, Ingo Molnar, Janakarajan Natarajan, Jim Mattson,
	Kan Liang, Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Wed, Dec 20, 2017 at 01:33:46AM +0200, Jarkko Sakkinen wrote:
> On Tue, 2017-12-12 at 15:07 +0100, Pavel Machek wrote:
> > On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > > 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.
> > > In a way you can think that SGX provides inverted sandbox. It protects the
> > > application from a malicious host.
> > 
> > Would you list guarantees provided by SGX?
> > 
> > For example, host can still observe timing of cachelines being
> > accessed by "protected" app, right? Can it also introduce bit flips?
> > 
> > 								Pavel
> 
> I'll give a more proper response to this now that all the reported major
> issues in the code have been fixed in v9.
> 
> Yes, SGX is vulnerable to the L1 cacheline timing attacks. Jethro
> Beekman wrote a great summary about this on early March:
> 
>   https://jbeekman.nl/blog/2017/03/sgx-side-channel-attacks/
> 
> The counter measures are the same as without SGX. It really does not
> add or degrade security in this area.

This came up even in my patch set :-) I.e. I switched to kernel AES-NI
from TinyCrypt's AES because the latter is not timing resistant.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-11-25 19:29 [PATCH v6 00/11] Intel SGX Driver Jarkko Sakkinen
  2017-11-25 19:29 ` [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
  2017-12-12 14:07 ` [PATCH v6 00/11] Intel SGX Driver Pavel Machek
@ 2018-01-04 14:17 ` Cedric Blancher
  2018-01-04 14:27   ` Greg Kroah-Hartman
                     ` (2 more replies)
  2 siblings, 3 replies; 31+ messages in thread
From: Cedric Blancher @ 2018-01-04 14:17 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: platform-driver-x86, x86, Linux Kernel Mailing List,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

So how does this protect against the MELTDOWN attack (CVE-2017-5754)
and the MELTATOMBOMBA4 worm which uses this exploit?

Ced

On 25 November 2017 at 20:29, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> 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.
> In a way you can think that SGX provides inverted sandbox. It protects the
> application from a malicious host.
>
> 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.
>
> You can tell if your CPU supports SGX by looking into /proc/cpuinfo:
>
>         cat /proc/cpuinfo  | grep sgx
>
> The GIT repositoy for SGX driver resides in
>
>         https://github.com/jsakkine-intel/linux-sgx.git
>
> 'le' branch contains the upstream candidate patches.
>
> 'master' branch contains the same patches with the following differences:
>
> * top-level patch modifies the ioctl API to be SDK compatible
> * does not use flexible launch control but instead relies on SDK provided
>   Intel launch enclave.
>
> Backlog:
> * AES: how to use arch/x86/crypto/aesni-intel_asm.S from the enclave. I
>   guess these routines should be fairly easy to call directly (haven't
>   investigated deeply). Any advice is appreciated.
> * Layout: what and where to place in arch/x86.
> * MAINTAINERS: who to add as reviewer.
>
> 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()
>
>
> Haim Cohen (1):
>   x86: add SGX MSRs to msr-index.h
>
> Jarkko Sakkinen (8):
>   intel_sgx: updated MAINTAINERS
>   x86: define IA32_FEATUE_CONTROL.SGX_LC
>   intel_sgx: driver for Intel Software Guard Extensions
>   intel_sgx: ptrace() support
>   intel_sgx: in-kernel launch enclave
>   fs/pipe.c: export create_pipe_files() and replace_fd()
>   intel_sgx: glue code for in-kernel LE
>   intel_sgx: driver documentation
>
> Kai Huang (1):
>   x86: add SGX definition to cpufeature
>
> Sean Christopherson (1):
>   x86: define IA32_FEATURE_CONTROL.SGX_ENABLE
>
>  Documentation/index.rst                            |   1 +
>  Documentation/x86/intel_sgx.rst                    | 101 +++
>  MAINTAINERS                                        |   5 +
>  arch/x86/include/asm/cpufeatures.h                 |   2 +
>  arch/x86/include/asm/msr-index.h                   |   8 +
>  arch/x86/include/asm/sgx.h                         | 233 +++++
>  arch/x86/include/asm/sgx_arch.h                    | 268 ++++++
>  arch/x86/include/uapi/asm/sgx.h                    | 138 +++
>  drivers/platform/x86/Kconfig                       |   2 +
>  drivers/platform/x86/Makefile                      |   1 +
>  drivers/platform/x86/intel_sgx/Kconfig             |  34 +
>  drivers/platform/x86/intel_sgx/Makefile            |  32 +
>  drivers/platform/x86/intel_sgx/le/Makefile         |  26 +
>  drivers/platform/x86/intel_sgx/le/enclave/Makefile |  46 +
>  .../x86/intel_sgx/le/enclave/aes_encrypt.c         | 191 ++++
>  .../platform/x86/intel_sgx/le/enclave/cmac_mode.c  | 254 ++++++
>  .../x86/intel_sgx/le/enclave/encl_bootstrap.S      | 163 ++++
>  .../intel_sgx/le/enclave/include/tinycrypt/aes.h   | 133 +++
>  .../le/enclave/include/tinycrypt/cmac_mode.h       | 194 ++++
>  .../le/enclave/include/tinycrypt/constants.h       |  59 ++
>  .../intel_sgx/le/enclave/include/tinycrypt/utils.h |  95 ++
>  drivers/platform/x86/intel_sgx/le/enclave/main.c   | 203 +++++
>  .../platform/x86/intel_sgx/le/enclave/sgx_le.lds   |  28 +
>  .../platform/x86/intel_sgx/le/enclave/sgxsign.c    | 538 +++++++++++
>  drivers/platform/x86/intel_sgx/le/enclave/utils.c  |  78 ++
>  drivers/platform/x86/intel_sgx/le/entry.S          | 117 +++
>  .../platform/x86/intel_sgx/le/include/sgx_asm.h    |  64 ++
>  .../platform/x86/intel_sgx/le/include/sgx_encl.h   | 110 +++
>  drivers/platform/x86/intel_sgx/le/main.c           | 214 +++++
>  drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S   |  15 +
>  drivers/platform/x86/intel_sgx/sgx.h               | 268 ++++++
>  drivers/platform/x86/intel_sgx/sgx_encl.c          | 999 +++++++++++++++++++++
>  drivers/platform/x86/intel_sgx/sgx_ioctl.c         | 282 ++++++
>  drivers/platform/x86/intel_sgx/sgx_le.c            | 319 +++++++
>  .../platform/x86/intel_sgx/sgx_le_proxy_piggy.S    |  15 +
>  drivers/platform/x86/intel_sgx/sgx_main.c          | 456 ++++++++++
>  drivers/platform/x86/intel_sgx/sgx_page_cache.c    | 619 +++++++++++++
>  drivers/platform/x86/intel_sgx/sgx_util.c          | 394 ++++++++
>  drivers/platform/x86/intel_sgx/sgx_vma.c           | 236 +++++
>  fs/file.c                                          |   1 +
>  fs/pipe.c                                          |   1 +
>  41 files changed, 6943 insertions(+)
>  create mode 100644 Documentation/x86/intel_sgx.rst
>  create mode 100644 arch/x86/include/asm/sgx.h
>  create mode 100644 arch/x86/include/asm/sgx_arch.h
>  create mode 100644 arch/x86/include/uapi/asm/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
>  create mode 100644 drivers/platform/x86/intel_sgx/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/aes_encrypt.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/encl_bootstrap.S
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/aes.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/cmac_mode.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/constants.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/utils.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgx_le.lds
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgxsign.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/utils.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/entry.S
>  create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_asm.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_encl.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
>
> --
> 2.14.1
>



-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-04 14:17 ` Cedric Blancher
@ 2018-01-04 14:27   ` Greg Kroah-Hartman
  2018-01-04 15:08   ` James Bottomley
  2018-01-09 14:27   ` Jarkko Sakkinen
  2 siblings, 0 replies; 31+ messages in thread
From: Greg Kroah-Hartman @ 2018-01-04 14:27 UTC (permalink / raw)
  To: Cedric Blancher
  Cc: Jarkko Sakkinen, platform-driver-x86, x86,
	Linux Kernel Mailing List, Borislav Petkov, David S. Miller,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?

It has nothing to do with it at all, sorry.

greg k-h

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-04 14:17 ` Cedric Blancher
  2018-01-04 14:27   ` Greg Kroah-Hartman
@ 2018-01-04 15:08   ` James Bottomley
  2018-01-09 14:27   ` Jarkko Sakkinen
  2 siblings, 0 replies; 31+ messages in thread
From: James Bottomley @ 2018-01-04 15:08 UTC (permalink / raw)
  To: Cedric Blancher, Jarkko Sakkinen
  Cc: platform-driver-x86, x86, Linux Kernel Mailing List,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Thu, 2018-01-04 at 15:17 +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?

Actually, a data exfiltration attack against SGX, using page tables has
already been documented:

https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/van-bulck

It doesn't exploit speculation as the mechanism for gathering data (it
exploits page faults), but the structure of the side channel attack
used to exfiltrate data from the supposedly secure enclave is very
similar to Spectre.  The targetting mechanism is very different,
though: the page table exploit assumes you can control the page tables,
so you must be highly privileged on the platform but with Spectre you
merely have to be an ordinary user.

James

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-04 14:17 ` Cedric Blancher
  2018-01-04 14:27   ` Greg Kroah-Hartman
  2018-01-04 15:08   ` James Bottomley
@ 2018-01-09 14:27   ` Jarkko Sakkinen
  2018-02-08  8:46     ` Pavel Machek
  2 siblings, 1 reply; 31+ messages in thread
From: Jarkko Sakkinen @ 2018-01-09 14:27 UTC (permalink / raw)
  To: Cedric Blancher
  Cc: platform-driver-x86, x86, Linux Kernel Mailing List,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?
> 
> Ced

Everything going out of L1 gets encrypted. This is done to defend
against peripheral like adversaries and should work also against
meltdown.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-09 14:27   ` Jarkko Sakkinen
@ 2018-02-08  8:46     ` Pavel Machek
  2018-02-08 13:48       ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Pavel Machek @ 2018-02-08  8:46 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Cedric Blancher, platform-driver-x86, x86,
	Linux Kernel Mailing List, Borislav Petkov, David S. Miller,
	Greg Kroah-Hartman, Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

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

On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote:
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4 worm which uses this exploit?
> > 
> > Ced
> 
> Everything going out of L1 gets encrypted. This is done to defend
> against peripheral like adversaries and should work also against
> meltdown.

Yeah, but useless against spectre and ability to introduce bit flips
means this is generally useless...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-02-08  8:46     ` Pavel Machek
@ 2018-02-08 13:48       ` Jarkko Sakkinen
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2018-02-08 13:48 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Cedric Blancher, platform-driver-x86, x86,
	Linux Kernel Mailing List, Borislav Petkov, David S. Miller,
	Greg Kroah-Hartman, Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Thu, Feb 08, 2018 at 09:46:53AM +0100, Pavel Machek wrote:
> On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote:
> > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > > and the MELTATOMBOMBA4 worm which uses this exploit?
> > > 
> > > Ced
> > 
> > Everything going out of L1 gets encrypted. This is done to defend
> > against peripheral like adversaries and should work also against
> > meltdown.
> 
> Yeah, but useless against spectre and ability to introduce bit flips
> means this is generally useless...

You are right.

And what I said was simply false. In fact, the encryption is done in
LCC.  I'm sorry that I didn't response to my response and gave incorrect
info. I simply forgot to do this, no other excuses.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-09 21:50 Dr. Greg Wettstein
@ 2018-01-10 16:16 ` Jarkko Sakkinen
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2018-01-10 16:16 UTC (permalink / raw)
  To: greg
  Cc: Pavel Machek, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Tue, Jan 09, 2018 at 03:50:23PM -0600, Dr. Greg Wettstein wrote:
> > Everything going out of L1 gets encrypted. This is done to defend
> > against peripheral like adversaries and should work also against
> > meltdown.
> 
> I don't believe this is an architecturally correct assertion.  The
> encryption/decryption occurs at the 'bottom' of the cache heirarchy.

You are right and I was wrong. It is plain from L1 to LLC, which implies
as you correctly described potential cache missing attacks in addition
to timing attacks.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
@ 2018-01-09 21:50 Dr. Greg Wettstein
  2018-01-10 16:16 ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Dr. Greg Wettstein @ 2018-01-09 21:50 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Pavel Machek, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Jan 9,  4:25pm, Jarkko Sakkinen wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Good afternoon I hope the week is going well for everyone.

In order to minimize spamming mailboxes with two mails I'm
incorporating a reply to Jarkko's second e-mail on the Memory
Encryption Engine below as well, since the issues are all related.

> On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> > If we are talking about the issues motivating the KPTI work I don't
> > have any useful information beyond what is raging through the industry
> > right now.
> > 
> > With respect to SGX, the issues giving rise to KPTI are characteristic
> > of what this technology is designed to address.  The technical 'news'
> > sites, which are even more of an abomination then usual with this
> > issue, are talking about privileged information such as credentials,
> > passwords et.al being leaked by this vulnerability.
> > 
> > Data committed to enclaves are only accessible by the enclave, even
> > the kernel, by definition, can't access the memory.  Given current
> > events that is an arguably useful behavior.

> Exactly. You could think adversary using meltdown leak utilizing
> malware as having same capabilities as peripheral connected to a
> bus, which we can defend against with SGX.

I believe caution needs to be applied to these statements

Since we design high assurance computing devices that use SGX to
protect our autonomous introspection engine, we obviously have very
significant concerns regarding whether the SGX security guarantees are
still operative in the face of these micro-architectural probing
attacks.  Absent official guidance, we have been pouring over the SGX
architectural documents for a week in order to develop risk guidance.

Based on that review, our conclusion was that there was nothing
inherent in the SGX architectural model that implies protection
against confidentiality losses through micro-architectural side
channel inspection.  Our conclusion was reinforced by a group in
London which has reportedly demonstrated the effectiveness of the
conditional branch misprediction exploit against data processed inside
of an enclave.

We have not yet verified the exploit in our lab, but given our
architectural review there would seem to be no reason why it shouldn't
work.  I posted a note to the SGX developer's forum early this morning
with a summary of our analysis but haven't received any responses.

To 'wit in summary.

In this attack scenario, the potential lack of confidentiality inside
of an enclave is the same as if the code was running in unprotected
memory space.  The MM{U,E} infrastructure is servicing micro-op
resource requests for instructions inside of an enclave, just as it
would normally do in untrusted space.  As a result, code running in an
enclave induces cache state changes which can be externally probed,
ie. the effects of a forced branch mispredict on cache state are the
same if the code executes inside of an enclave as if it were in
untrusted memory.

As I noted in my post to the SGX forum, this would be really
interesting if it could be done by an arbitrary process against an
enclave.  As the sample code demonstrates however, the exploit binary
has to be able to invoke at last two ECALL's (invocation of functions
in trusted space) in order to carry out the attack.  This is somewhat
analogous to an exploit where a process is able to attack its own
memory map.

With respect to the other mail:

> Everything going out of L1 gets encrypted. This is done to defend
> against peripheral like adversaries and should work also against
> meltdown.

I don't believe this is an architecturally correct assertion.  The
encryption/decryption occurs at the 'bottom' of the cache heirarchy.

Based on Shay Gueron's paper, which describes the Memory Encryption
Engine (MEE) and its security characteristics and proofs, the MEE acts
as an extension of the memory controller and mediates CACHE<->DRAM
traffic to the Enclave Page Cache (EPC), ie, the protected data
region.  It is responsible for encrypting and decrypting page data as
well as the generation of the tags which are used to populate the
Merkle integrity tree.

As I mentioned in a previous mail, the MEE is responsible for emitting
the 'drop and lock' verification signal which locks the memory
controller if a memory integrity check fails.  This is to support a
fundamental design tenant of the architecture that no unverified data
reaches the caches.

Based on this I believe all of the data in the caches is in plaintext,
not just from L1 upward.  So by inference, speculative execution is
able to induce the population of the caches with unencrypted data and
act on those results.  If this were not the case it would be difficult
to understand how the demonstrated branch mispredict attack could be
successful.

With respect to protecting access to memory, the SGX modified Page
Miss Handler (PMH) is designed to deny the final population of a TLB
slot if the page is from an 'untrusted' virtual<->physical mapping.
This occurs even later then the standard page access controls and it
was the 'lateness' of those checks, in comparison to the actual
population of the caches, which proved to be the particularly
problematic issue in Meltdown.

As a result, we remain very uneasy with respect to the confidentiality
guarantees that are available in the face of these attacks.  Luckily
we depend on the architecture for integrity.

> /Jarkko

We will try and see if we can get some engineering time to reproducing
the branch mispredict exploit that was published and report back.

Have a good evening.

Dr. Greg

}-- End of excerpt from Jarkko Sakkinen

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           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] 31+ messages in thread

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-04  9:06 Dr. Greg Wettstein
@ 2018-01-09 14:25 ` Jarkko Sakkinen
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Sakkinen @ 2018-01-09 14:25 UTC (permalink / raw)
  To: greg
  Cc: Pavel Machek, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> If we are talking about the issues motivating the KPTI work I don't
> have any useful information beyond what is raging through the industry
> right now.
> 
> With respect to SGX, the issues giving rise to KPTI are characteristic
> of what this technology is designed to address.  The technical 'news'
> sites, which are even more of an abomination then usual with this
> issue, are talking about privileged information such as credentials,
> passwords et.al being leaked by this vulnerability.
> 
> Data committed to enclaves are only accessible by the enclave, even
> the kernel, by definition, can't access the memory.  Given current
> events that is an arguably useful behavior.

Exactly. You could think adversary using meltdown leak utilizing malware
as having same capabilities as peripheral connected to a bus, which we
can defend against with SGX.

/Jarkko

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

* Re: [PATCH v6 00/11] Intel SGX Driver
@ 2018-01-04 21:09 Dr. Greg Wettstein
  0 siblings, 0 replies; 31+ messages in thread
From: Dr. Greg Wettstein @ 2018-01-04 21:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Cedric Blancher
  Cc: Jarkko Sakkinen, platform-driver-x86, x86,
	Linux Kernel Mailing List, Borislav Petkov, David S. Miller,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc,
	Radim Krčmář,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Jan 4,  3:27pm, Greg Kroah-Hartman wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Wild day, enjoyed by all I'm sure.

> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4 worm which uses this exploit?

> It has nothing to do with it at all, sorry.

Precision seems to be everything in these discussions.

Since SGX obviously does not mitigate micro-architectural state
probing it is not an effective general remediation against MELTDOWN.
Does your statement indicate there is solid documentation that
MELTDOWN can be used by a process of any privilege level to dump out
the unencrypted contents of an initialized enclave?

That would obviously be a big story as well.

> greg k-h

Have a good evening.

Greg

}-- End of excerpt from Greg Kroah-Hartman

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           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] 31+ messages in thread

* Re: [PATCH v6 00/11] Intel SGX Driver
@ 2018-01-04  9:06 Dr. Greg Wettstein
  2018-01-09 14:25 ` Jarkko Sakkinen
  0 siblings, 1 reply; 31+ messages in thread
From: Dr. Greg Wettstein @ 2018-01-04  9:06 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Jarkko Sakkinen, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Jan 3, 10:48am, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> Hi!

Good morning.

> :-). Stuff proceeds as usual. Too bad it is raining outside, instead
> of snowing.

-19C here, so we have snow... :-)

> > > So ... even with SGX, host can generate bitflips in the enclave,
> > > right?

> > Correct.

> I'd say that you can't generate bitflips because if you do hardware
> will kill the enclave. This seems to be significant difference from
> AMD "secure" memory encryption.

SGX is an entirely different class of technology compared to AME SME
or the Intel equivalent TME (Total Memory Encryption).  Both of these
are best described as the notion of applying the concept of whole disk
encryption to memory.

There are lots of well understood issues surrounding this approach,
whether the target is memory pages or disk sectors.  I think the issue
comes down to the fact that there is a desire to enable a BIOS option
and become 'secure', unfortunately the world is not that simple.

> > Forcing a bitflip in enclave memory causes the next page fetch
> > containing the bitflipped location to fail its integrity check.
> > Since this technically shouldn't be possible, this situation was
> > classified as a hardware failure which is handled by the processor
> > locking its execution state, thus taking the machine down.

> So you can't really do bitflips on the SGX protected memory, because
> MM{E,U} hardware will catch that and kill machine if you try?

Correct.

Which obviously has issues in a multi-tenant cloud environment, but
again, it comes down to risk management.  Killing a machine is
problematic, a massive data compromise isn't much fun either.

> So SGX protected memory is not swappable?

The architecture provides support for swapping enclave pages and the
Linux driver supports it.

The swapped pages retain their confidentiality and integrity
protections.

> > It would seem to be a misfeature for the self-protection mechanism to
> > not generate some type of trappable fault rather then generating a
> > processor lockup but hindsight is always 20/20.  Philosophically this
> > is a good example of security risk managment.  Locking a machine is
> > obviously problematic in a cloud service environment, but it has to be
> > taken in the perspective of whether or not it would be preferable to
> > have a successful privilege escalation attack which could result in
> > exfiltration of sensitive data.

> Ok, right, it should fault. They can fix it in new version?

Good question and something only Intel can answer.

A large part of SGX is implemented in microcode, in part due to the
complexity of the technologies involved, notably the group signing
(EPID) implementation.

Beyond that, there was a specific acknowledgement that this was
security sensitive code and may need an upgrade, hence the microcode
implementation.

Since the drop and lock 'feature' is closely tied to the MM{E,U}
implementation, the question would be whether or not this behavior
could be changed with updated firmware.  If it was easy to change the
behavior of the MMU with microcode the industry would be less frantic
right now... :-)

If it would be possible to change the drop and lock response it would
arguably improve the utility of the technology in certain
environments.  SGX2 would have been a great time for that.

> > Arguably not as much fun as what appears to be pending, given what
> > appears to be the difficulty of some Intel processors to deal with
> > page faults induced by speculative memory references... :-)

> Do you have more info on that? Will they actually leak information,
> or is it just good for rowhammering the kernel memory?

If we are talking about the issues motivating the KPTI work I don't
have any useful information beyond what is raging through the industry
right now.

With respect to SGX, the issues giving rise to KPTI are characteristic
of what this technology is designed to address.  The technical 'news'
sites, which are even more of an abomination then usual with this
issue, are talking about privileged information such as credentials,
passwords et.al being leaked by this vulnerability.

Data committed to enclaves are only accessible by the enclave, even
the kernel, by definition, can't access the memory.  Given current
events that is an arguably useful behavior.

> Best regards,
> 									Pavel

Stay dry.

Have a good day.

Greg

}-- End of excerpt from Pavel Machek

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Lots of folks confuse bad management with destiny."
                                -- Kin Hubbard

-- 

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2018-01-03  0:59 Dr. Greg Wettstein
@ 2018-01-03  9:48 ` Pavel Machek
  0 siblings, 0 replies; 31+ messages in thread
From: Pavel Machek @ 2018-01-03  9:48 UTC (permalink / raw)
  To: greg
  Cc: Jarkko Sakkinen, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

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

Hi!

> Good evening Pavel et.al., I hope the New Year has started well for
> everyone.

:-). Stuff proceeds as usual. Too bad it is raining outside, instead
of snowing.

> > > > Would you list guarantees provided by SGX?
> > >
> > > Obviously, confidentiality and integrity.  SGX was designed to address
> > > an Iago threat model, a very difficult challenge to address in
> > > reality.
> 
> > Do you have link on "Iago threat model"?
> 
> https://cseweb.ucsd.edu/~hovav/dist/iago.pdf
> 
> > > I don't have the citation immediately available, but a bit-flip attack
> > > has also been described on enclaves.  Due to the nature of the
> > > architecture, they tend to crash the enclave so they are more in the
> > > category of a denial-of-service attack, rather then a functional
> > > confidentiality or integrity compromise.
> 
> > So ... even with SGX, host can generate bitflips in the enclave,
> > right?
> 
> Correct.

...

I'd say that you can't generate bitflips because if you do hardware
will kill the enclave. This seems to be significant difference from
AMD "secure" memory encryption...

> > People usually assume that bitflip will lead "only" to
> > denial-of-service, but rowhammer work shows that even "random" bit
> > flips easily lead to priviledge escalation on javascript virtual
> > machines, and in similar way you can get root if you have user and
> > bit flips happen.
> >
> > So... I believe we should assume compromise is possible, not just
> > denial-of-service.
> 
> Prudence always dictates that one assumes the worst.  In this case
> however, the bitflip attacks against SGX enclaves are very definitely
> in the denial-of-service category.  The attack is designed to trigger
> a hardware self-protection feature on the processor.
> 
> Each page of memory which is initialized into an enclave has a
> metadata block associated with it which contains the integrity state
> of that page of memory.  The MM{E,U} hardware on an SGX capable
> platform checks this integrity data on each page fetch request arising
> from addresses/pages inside of an enclave.
> 
> Forcing a bitflip in enclave memory causes the next page fetch
> containing the bitflipped location to fail its integrity check.  Since
> this technically shouldn't be possible, this situation was classified
> as a hardware failure which is handled by the processor locking its
> execution state, thus taking the machine down.

So you can't really do bitflips on the SGX protected memory, because
MM{E,U} hardware will catch that and kill machine if you try?

So SGX protected memory is not swappable?

> It would seem to be a misfeature for the self-protection mechanism to
> not generate some type of trappable fault rather then generating a
> processor lockup but hindsight is always 20/20.  Philosophically this
> is a good example of security risk managment.  Locking a machine is
> obviously problematic in a cloud service environment, but it has to be
> taken in the perspective of whether or not it would be preferable to
> have a successful privilege escalation attack which could result in
> exfiltration of sensitive data.

Ok, right, it should fault. They can fix it in new version?

> > Well, yes :-). And I believe someone is going to have fun with SGX
> > ;-).
> 
> Arguably not as much fun as what appears to be pending, given what
> appears to be the difficulty of some Intel processors to deal with
> page faults induced by speculative memory references... :-)

Do you have more info on that? Will they actually leak information, or
is it just good for rowhammering the kernel memory?


Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

* Re: [PATCH v6 00/11] Intel SGX Driver
@ 2018-01-03  0:59 Dr. Greg Wettstein
  2018-01-03  9:48 ` Pavel Machek
  0 siblings, 1 reply; 31+ messages in thread
From: Dr. Greg Wettstein @ 2018-01-03  0:59 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Jarkko Sakkinen, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Dec 27,  9:46pm, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> Hi!

Good evening Pavel et.al., I hope the New Year has started well for
everyone.

> > > Would you list guarantees provided by SGX?
> >
> > Obviously, confidentiality and integrity.  SGX was designed to address
> > an Iago threat model, a very difficult challenge to address in
> > reality.

> Do you have link on "Iago threat model"?

https://cseweb.ucsd.edu/~hovav/dist/iago.pdf

> > I don't have the citation immediately available, but a bit-flip attack
> > has also been described on enclaves.  Due to the nature of the
> > architecture, they tend to crash the enclave so they are more in the
> > category of a denial-of-service attack, rather then a functional
> > confidentiality or integrity compromise.

> So ... even with SGX, host can generate bitflips in the enclave,
> right?

Correct.

Here is the reference I was trying to recall in my last e-mail:

https://sslab.gtisc.gatech.edu/assets/papers/2017/jang:sgx-bomb.pdf

> People usually assume that bitflip will lead "only" to
> denial-of-service, but rowhammer work shows that even "random" bit
> flips easily lead to priviledge escalation on javascript virtual
> machines, and in similar way you can get root if you have user and
> bit flips happen.
>
> So... I believe we should assume compromise is possible, not just
> denial-of-service.

Prudence always dictates that one assumes the worst.  In this case
however, the bitflip attacks against SGX enclaves are very definitely
in the denial-of-service category.  The attack is designed to trigger
a hardware self-protection feature on the processor.

Each page of memory which is initialized into an enclave has a
metadata block associated with it which contains the integrity state
of that page of memory.  The MM{E,U} hardware on an SGX capable
platform checks this integrity data on each page fetch request arising
from addresses/pages inside of an enclave.

Forcing a bitflip in enclave memory causes the next page fetch
containing the bitflipped location to fail its integrity check.  Since
this technically shouldn't be possible, this situation was classified
as a hardware failure which is handled by the processor locking its
execution state, thus taking the machine down.

It would seem to be a misfeature for the self-protection mechanism to
not generate some type of trappable fault rather then generating a
processor lockup but hindsight is always 20/20.  Philosophically this
is a good example of security risk managment.  Locking a machine is
obviously problematic in a cloud service environment, but it has to be
taken in the perspective of whether or not it would be preferable to
have a successful privilege escalation attack which could result in
exfiltration of sensitive data.

Philosophically we take the approach that for high security assurance
environments it is virtually impossible to allow any untrusted code to
run on a platform.  Which is why we focus on autonomous introspection
for these environments.

> > Unfortunately, in the security field it is way more fun, and
> > seemingly advantageous from a reputational perspective, to break
> > things then to build solutions.... :-)(

> Well, yes :-). And I believe someone is going to have fun with SGX
> ;-).
> 									Pavel

Arguably not as much fun as what appears to be pending, given what
appears to be the difficulty of some Intel processors to deal with
page faults induced by speculative memory references... :-)

Best wishes for a productive New Year.

Dr. Greg

}-- End of excerpt from Pavel Machek

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"It is difficult to produce a television documentary that is both
 incisive and probing when every twelve minutes one is interrupted by
 twelve dancing rabbits singing about toilet paper."
                                -- Rod Serling

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

* Re: [PATCH v6 00/11] Intel SGX Driver
  2017-12-27 10:30 Dr. Greg Wettstein
@ 2017-12-27 20:46 ` Pavel Machek
  0 siblings, 0 replies; 31+ messages in thread
From: Pavel Machek @ 2017-12-27 20:46 UTC (permalink / raw)
  To: greg
  Cc: Jarkko Sakkinen, platform-driver-x86, x86, linux-kernel,
	Borislav Petkov, David S. Miller, Greg Kroah-Hartman,
	Grzegorz Andrejczuk, Haim Cohen, Ingo Molnar,
	Janakarajan Natarajan, Jim Mattson, Kan Liang,
	Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

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

Hi!

> > Would you list guarantees provided by SGX?
> 
> Obviously, confidentiality and integrity.  SGX was designed to address
> an Iago threat model, a very difficult challenge to address in
> reality.

Do you have link on "Iago threat model"?

> I don't have the citation immediately available, but a bit-flip attack
> has also been described on enclaves.  Due to the nature of the
> architecture, they tend to crash the enclave so they are more in the
> category of a denial-of-service attack, rather then a functional
> confidentiality or integrity compromise.

So ... even with SGX, host can generate bitflips in the enclave,
right?

People usually assume that bitflip will lead "only" to
denial-of-service, but rowhammer work shows that even "random" bit
flips easily lead to priviledge escalation on javascript virtual
machines, and in similar way you can get root if you have user and bit
flips happen.

So... I believe we should assume compromise is possible, not just
denial-of-service.

> Unfortunately, in the security field it is way more fun, and seemingly
> advantageous from a reputational perspective, to break things then to
> build solutions.... :-)(

Well, yes :-). And I believe someone is going to have fun with SGX
;-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

* Re: [PATCH v6 00/11] Intel SGX Driver
@ 2017-12-27 10:30 Dr. Greg Wettstein
  2017-12-27 20:46 ` Pavel Machek
  0 siblings, 1 reply; 31+ messages in thread
From: Dr. Greg Wettstein @ 2017-12-27 10:30 UTC (permalink / raw)
  To: Pavel Machek, Jarkko Sakkinen
  Cc: platform-driver-x86, x86, linux-kernel, Borislav Petkov,
	David S. Miller, Greg Kroah-Hartman, Grzegorz Andrejczuk,
	Haim Cohen, Ingo Molnar, Janakarajan Natarajan, Jim Mattson,
	Kan Liang, Kirill A. Shutemov, Kyle Huey, Len Brown,
	open list:DOCUMENTATION,
	open list:FILESYSTEMS (VFS and infrastructure),
	Mauro Carvalho Chehab, Paolo Bonzini, Piotr Luc, Radim Kr??m????,
	Randy Dunlap, Sean Christopherson, Thomas Gleixner, Tom Lendacky,
	Vikas Shivappa

On Dec 12,  3:07pm, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Good morning, I hope this note finds the holiday season going well for
everyone.  This note is a bit delayed due to the holidays, my
apologies.

Pretty wide swath on this e-mail but will include the copy list due to
the possible general interest and impact of these issues.  We have
done an independent implementation of Intel's platform software (PSW),
directed at the use of SGX on intelligent network endpoint devices, so
we have some experience with the issues under discussion.

> On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > 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.  In a way you can think
> > that SGX provides inverted sandbox. It protects the application
> > from a malicious host.

> Would you list guarantees provided by SGX?

Obviously, confidentiality and integrity.  SGX was designed to address
an Iago threat model, a very difficult challenge to address in
reality.

On SGX capable platforms, the Memory Encryption Engine (MEE) is an
integrated component of the hardware MMU, as SGX is a virtual memory
play.  As a result, the executable code and data are encrypted in main
memory and only decrypted when the data is fed from memory onto the
hardware fetch queues.  Irregardless of anything else, this has
implications with respect to cold boot attacks, if an architect
chooses to worry about that threat modality.

In reality, we believe the guarantee that is most important is
integrity, given the issues below.

> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?

Timing attacks are the bane of SGX, just as they are throughout the
rest of the commodity architectures.  Jarkko cited Beecham's work,
which is a good reference.  Oakland's work on controlled side-channel
attacks is also a very good, and fundamental, read on the issues
involved.

Microsoft Research and Georgia Tech have a paper out discussing the
use of transactional memory to mitigate these.

I don't have the citation immediately available, but a bit-flip attack
has also been described on enclaves.  Due to the nature of the
architecture, they tend to crash the enclave so they are more in the
category of a denial-of-service attack, rather then a functional
confidentiality or integrity compromise.

At the end of the day, giving up complete observational and functional
control to an adversary is a difficult challenge to address.  There is
also a large difference between attacks that can be conducted in a
carefully controlled lab environment and what an adversary or malware
can implement in practice.

Platforms which require security assurances ultimately need a root of
trust.  That either comes from a TPM or a Trusted Execution
Environment like SGX.  Realistically, we think the future involves an
integration of both technologies.  The only other alternative is
perfect software and I think the jury has already weighed in on that.

The advantage of SGX over a TPM is that it is blindingly fast with
respect to performance.  The IMA community has been involved in a
debate over the list digest patches in order to overcome performance
issues with TPM based extension measurements.  We lifted most of the
IMA infrastructure into an SGX enclave and demonstrated significant
performance impacts as a result.

The bigger question, for community integration, is the availability of
hardware.  I see Jarkko's patches are based on the notion of having
flexible launch control available, ie. the ability to program the
relevant MSR's with the checksum of the identity modulus which is to
serve as the root of trust.  I'm not sure there is any hardware in the
wild that currently supports this, Jarkko comments?

Even with that, the question arises as to what is going to be trusted
to program those registers.  The obvious candidate for this is
TXT/tboot which underscores a future involving the integration of
these technologies.

Unfortunately, in the security field it is way more fun, and seemingly
advantageous from a reputational perspective, to break things then to
build solutions.... :-)(

> Pavel

I hope the above clarifications are helpful.

Best wishes for a pleasant holiday weekend to everyone.

Dr. Greg

}-- End of excerpt from Pavel Machek

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"I suppose that could could happen but he wouldn't know a Galois Field
 if it kicked him in the nuts."
                                -- Anonymous mathematician
                                   Resurrection.

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

end of thread, other threads:[~2018-02-08 13:48 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-25 19:29 [PATCH v6 00/11] Intel SGX Driver Jarkko Sakkinen
2017-11-25 19:29 ` [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
2017-11-28 14:35   ` Christoph Hellwig
2017-11-28 20:42     ` Jarkko Sakkinen
2017-11-28 21:05       ` Christoph Hellwig
2017-11-28 21:57         ` Jarkko Sakkinen
2017-11-29 23:13           ` Christoph Hellwig
2017-11-30 16:43             ` Jarkko Sakkinen
2017-11-30 18:38               ` James Bottomley
2017-12-04  9:00                 ` Jarkko Sakkinen
2017-12-07 17:37                   ` Jarkko Sakkinen
2017-12-08 13:05                     ` Jarkko Sakkinen
2017-12-12 14:07 ` [PATCH v6 00/11] Intel SGX Driver Pavel Machek
2017-12-14 11:18   ` Jarkko Sakkinen
2017-12-19 23:33   ` Jarkko Sakkinen
2017-12-20 13:18     ` Jarkko Sakkinen
2018-01-04 14:17 ` Cedric Blancher
2018-01-04 14:27   ` Greg Kroah-Hartman
2018-01-04 15:08   ` James Bottomley
2018-01-09 14:27   ` Jarkko Sakkinen
2018-02-08  8:46     ` Pavel Machek
2018-02-08 13:48       ` Jarkko Sakkinen
2017-12-27 10:30 Dr. Greg Wettstein
2017-12-27 20:46 ` Pavel Machek
2018-01-03  0:59 Dr. Greg Wettstein
2018-01-03  9:48 ` Pavel Machek
2018-01-04  9:06 Dr. Greg Wettstein
2018-01-09 14:25 ` Jarkko Sakkinen
2018-01-04 21:09 Dr. Greg Wettstein
2018-01-09 21:50 Dr. Greg Wettstein
2018-01-10 16:16 ` Jarkko Sakkinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).