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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ messages in thread

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

Thread overview: 22+ 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

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