From: "Xing, Cedric" <cedric.xing@intel.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
Andy Lutomirski <luto@kernel.org>,
"Christopherson, Sean J" <sean.j.christopherson@intel.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
LSM List <linux-security-module@vger.kernel.org>,
Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@parisplace.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>,
Jethro Beekman <jethro@fortanix.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Dr. Greg" <greg@enjellic.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"nhorman@redhat.com" <nhorman@redhat.com>,
"npmccallum@redhat.com" <npmccallum@redhat.com>,
"Ayoun, Serge" <serge.ayoun@intel.com>,
"Katz-zamir, Shay" <shay.katz-zamir@intel.com>,
"Huang, Haitao" <haitao.huang@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"Svahn, Kai" <kai.svahn@intel.com>,
Borislav Petkov <bp@alien8.de>,
Josh Triplett <josh@joshtriplett.org>,
"Huang, Kai" <kai.huang@intel.com>,
David Rientjes <rientjes@google.com>
Subject: RE: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
Date: Fri, 24 May 2019 16:57:26 +0000 [thread overview]
Message-ID: <960B34DE67B9E140824F1DCDEC400C0F654E8D1E@ORSMSX116.amr.corp.intel.com> (raw)
In-Reply-To: <dda0912b-cb15-3c07-d368-345159e995f7@tycho.nsa.gov>
Hi Stephen,
> On 5/24/19 3:24 AM, Xing, Cedric wrote:
> >
> > When we talk about EPC page permissions with SGX2 in mind, I think we
> should distinguish between initial permissions and runtime permissions.
> Initial permissions refer to the page permissions set at EADD. They are
> technically set by "untrusted" code so should go by policies similar to
> those applicable to regular shared objects. Runtime permissions refer to
> the permissions granted by EMODPE, EAUG and EACCEPTCOPY. They are
> resulted from inherent behavior of the enclave, which in theory is
> determined by the enclave's measurements (MRENCLAVE and/or MRSIGNER).
> >
> > And we have 2 distinct files to work with - the enclave file and
> /dev/sgx/enclave. And I consider the enclave file a logical source for
> initial permissions while /dev/sgx/enclave is a means to control runtime
> permissions. Then we can have a simpler approach like the pseudo code
> below.
> >
> > /**
> > * Summary:
> > * - The enclave file resembles a shared object that contains
> RO/RX/RW segments
> > * - FILE__* are assigned to /dev/sgx/enclave, to determine
> acceptable permissions to mmap()/mprotect(), valid combinations are
> > * + FILE__READ - Allow SGX1 enclaves only
> > * + FILE__READ|FILE__WRITE - Allow SGX2 enclaves to expand data
> segments (e.g. heaps, stacks, etc.)
> > * + FILE__READ|FILE__WRITE|FILE__EXECUTE - Allow SGX2 enclaves to
> expend both data and code segments. This is necessary to support
> dynamically linked enclaves (e.g. Graphene)
> > * + FILE__READ|FILE__EXECUTE - Allow RW->RX changes for SGX1
> enclaves - necessary to support dynamically linked enclaves (e.g.
> Graphene) on SGX1. EXECMEM is also required for this to work
>
> I think EXECMOD would fit better than EXECMEM for this case; the former
> is applied for RW->RX changes for private file mappings while the latter
> is applied for WX private file mappings.
>
> > * + <None> - Disallow the calling process to launch any enclaves
> > */
> >
> > /* Step 1: mmap() the enclave file according to the segment attributes
> > (similar to what dlopen() would do for regular shared objects) */ int
> > image_fd = open("/path/to/enclave/file", O_RDONLY);
>
> FILE__READ checked to enclave file upon open().
Yes. We'd like to have the enclave file pass LSM/IMA checks and let EPC pages "inherit" the permissions from it as "initial" permissions.
>
> > foreach phdr in loadable segments /* phdr->p_type == PT_LOAD */ {
> > /* <segment permission> below is subject to LSM checks */
> > loadable_segments[i] = mmap(NULL, phdr->p_memsz, MAP_PRIATE,
> > <segment permission>, image_fd, phdr->p_offset);
>
> FILE__READ revalidated and FILE__EXECUTE checked to enclave file upon
> mmap() for PROT_READ and PROT_EXEC respectively. FILE__WRITE not
> checked even for PROT_WRITE mappings since it is a private file mapping
> and writes do not reach the file. EXECMEM checked if any segment
> permission has both W and X simultaneously. EXECMOD checked on any
> subsequent mprotect() RW->RX changes (if modified).
Yes. The intention here is to make sure all X pages come directly from file (unless EXECMEM or EXECMOD is granted). And because the driver will grant X only if the source page also has X, we can assert that all executable EPC pages are loaded from a file that has passed LSM/IMA checks.
>
> > }
> >
> > /* Step 2: Create enclave */
> > int enclave_fd = open("/dev/sgx/enclave", O_RDONLY /* or O_RDWR for
> > SGX2 enclaves */);
>
> FILE__READ checked (SGX1) or both FILE__READ and FILE__WRITE checked
> (SGX2) to /dev/sgx/enclave upon open(). Assuming that we are returning
> an open file referencing the /dev/sgx/enclave inode and not an anon
> inode, else we lose all subsequent FILE__* checking on mmap/mprotect and
> trigger EXECMEM on any mmap/mprotect PROT_EXEC.
Yes, the returned fd will be referencing /dev/sgx/enclave. The intention here is to limit EPC "runtime" permissions by the permissions granted to /dev/sgx/enclave, in order to allow user/administrator to specify what kinds of enclaves a given process can launch. Per your earlier comments, FILE__EXECMOD is probably also needed to support dynamically linked enclaves (that require RW->RX changes).
>
> > void *enclave_base = mmap(NULL, <enclave size>, MAP_SHARED, PROT_READ,
> > enclave_fd, 0); /* Only FILE__READ is required here */
>
> FILE__READ revalidated to /dev/sgx/enclave upon mmap().
Yes. This mmap() is to set "default" permissions for regions that do *not* have EPC pages populated. It is significant only for SGX2, to specify what action to take by the SGX driver upon #PF with those regions. For example, a R attempt (usually triggered by EACCEPT) within a RW region will cause SGX driver to EAUG a page at the fault address.
>
> > ioctl(enclave_fd, IOC_ECREATE, ...);
> >
> > /* Step 3: EADD and map initial EPC pages */ foreach s in
> > loadable_segments {
> > /* IOC_EADD_AND_MAP_SEGMENT will make sure s->perm is a subset of
> VMA permissions of the source pages, and use that as *both* EPCM and VMA
> permissions).
> > * Given enclave_fd may have FILE__READ only, LSM has to be
> bypassed so the "mmap" part has to be done inside the driver.
> > * Initial EPC pages will be mapped only once, so no inode is
> needed to remember the initial permissions. mmap/mprotect afterwards are
> subject to FILE__* on /dev/sgx/enclave
> > * The key point here is: permissions of source pages govern
> initial permissions of EADD'ed pages, regardless FILE__* on
> /dev/sgx/enclave
> > */
> > ioctl(enclave_fd, IOC_EADD_AND_MAP_SEGMENT, s->base, s->size,
> > s->perm...); }
> > /* EADD other enclave components, e.g. TCS, stacks, heaps, etc. */
> > ioctl(enclave_fd, IOC_EADD_AND_MAP_SEGMENT, tcs, 0x1000, RW |
> > PT_TCS...); ioctl(enclave_fd, IOC_EADD_AND_MAP_SEGMENT, <zero page>,
> > <stack size>, RW...); ...
> >
> > /* Step 4 (SGX2 only): Reserve ranges for additional heaps, stacks,
> > etc. */
> > /* FILE__WRITE required to allow expansion of data segments at runtime
> > */
> > /* Key point here is: permissions, if needed to change at runtime, are
> > subject to FILL__* on /dev/sgx/enclave */ mprotect(<heap address>,
> > <heap size>, PROT_READ | PROT_WRITE);
>
> FILE__READ and FILE__WRITE revalidated to /dev/sgx/enclave upon
> mprotect().
Yes. The intention here is to limit "runtime" permissions by accesses granted to the calling process to /dev/sgx/enclave. The "initial" permissions are set by ioctl to bypass LSM, because they are derived/determined by the enclave file.
Alternatively, the driver can remember "initial" permissions for each EPC page at IOC_EADD, to be committed at IOC_EINIT. Then this new IOC_EADD_AND_MAP will not be needed.
>
> >
> > /* Step 5: EINIT */
> > ioctl(IOC_EINIT, <sigstruct>...);
> >
> > /* Step 6 (SGX2 only): Set RX for dynamically loaded code pages (e.g.
> > Graphene, encrypted enclaves, etc.) as needed, at runtime */
> > /* FILE__EXECUTE required */
> > mprotect(<RX address>, <RX size>, PROT_READ | PROT_EXEC);
>
> FILE__READ revalidated and FILE__EXECUTE checked to /dev/sgx/enclave
> upon mprotect(). Cumulative set of checks at this point is
> FILE__READ|FILE__WRITE|FILE__EXECUTE.
>
> What would the step be for a SGX1 RW->RX change? How would that trigger
> EXECMOD? Do we really need to distinguish it from the SGX2 dynamically
> loaded code case?
Per your earlier comments, FILE__EXECMOD is also needed I think to allow RW->RX changes.
FILE__WRITE controls EAUG. I'm not judging its necessity, but just saying they are both valid combinations. To minimize impact to LSM, I don't want to special-case /dev/sgx/enclave. And the current semantics of FILE__* distinguish those two naturally.
BTW, there are usages, such as encrypted enclaves (https://github.com/intel/linux-sgx-pcl), requiring RW->RX but not EAUG. Graphene could also run on SGX1, provided that pages needed by shared objects are all pre-allocated before EINIT. All those could run without FILE__WRITE.
>
> >
> > -Cedric
> >
next prev parent reply other threads:[~2019-05-24 16:57 UTC|newest]
Thread overview: 318+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 10:39 [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 01/28] x86/cpufeatures: Add Intel-defined SGX feature bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 02/28] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits) Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 03/28] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 04/28] x86/cpufeatures: Add Intel-defined SGX_LC feature bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 05/28] x86/msr: Add SGX Launch Control MSR definitions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 06/28] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 07/28] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 08/28] x86/cpu/intel: Detect SGX support and update caps appropriately Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 09/28] x86/sgx: Add ENCLS architectural error codes Jarkko Sakkinen
2019-04-22 21:35 ` Sean Christopherson
2019-04-17 10:39 ` [PATCH v20 10/28] x86/sgx: Add SGX1 and SGX2 architectural data structures Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 11/28] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 12/28] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 13/28] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 14/28] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver Jarkko Sakkinen
2019-04-22 21:58 ` Sean Christopherson
2019-04-23 23:29 ` Jethro Beekman
2019-04-24 0:26 ` Sean Christopherson
2019-04-24 1:04 ` Jethro Beekman
2019-04-29 19:08 ` Sean Christopherson
2019-06-04 20:12 ` Sean Christopherson
2019-06-05 14:29 ` Jarkko Sakkinen
2019-06-05 14:52 ` Sean Christopherson
2019-06-05 21:25 ` Dr. Greg
2019-06-05 22:20 ` Sean Christopherson
2019-06-06 15:32 ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 16/28] x86/sgx: Add provisioning Jarkko Sakkinen
2019-04-19 3:06 ` Huang, Kai
2019-04-23 14:33 ` Jarkko Sakkinen
2019-04-24 1:34 ` Jethro Beekman
2019-05-02 8:27 ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 17/28] x86/sgx: Add swapping code to the core and SGX driver Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 18/28] x86/sgx: ptrace() support for the " Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 19/28] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 20/28] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 21/28] x86/fault: Attempt to fixup unhandled #PF in vDSO before signaling Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 22/28] x86/traps: Attempt to fixup exceptions " Jarkko Sakkinen
2019-06-25 15:43 ` Jarkko Sakkinen
2019-06-27 20:32 ` Xing, Cedric
2019-07-11 15:54 ` Sean Christopherson
2019-07-11 22:12 ` Xing, Cedric
2019-07-11 15:56 ` Sean Christopherson
2019-07-11 17:52 ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 23/28] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 24/28] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 25/28] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 26/28] docs: x86/sgx: Add Architecture documentation Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 27/28] docs: x86/sgx: Document kernel internals Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 28/28] docs: x86/sgx: Document the enclave API Jarkko Sakkinen
2019-04-18 17:10 ` [PATCH v20 00/28] Intel SGX1 support Dr. Greg
2019-04-18 17:24 ` Dave Hansen
2019-04-19 16:24 ` Dr. Greg
2019-04-19 16:39 ` Dave Hansen
2019-04-18 18:01 ` Dave Hansen
2019-04-19 14:17 ` Dr. Greg
2019-04-19 14:25 ` Dave Hansen
2019-04-19 15:27 ` Andy Lutomirski
2019-04-19 19:38 ` Jethro Beekman
2019-04-19 20:39 ` Thomas Gleixner
2019-04-19 20:46 ` Jethro Beekman
2019-04-19 20:50 ` Thomas Gleixner
2019-04-19 20:54 ` Jethro Beekman
2019-04-19 21:15 ` Andy Lutomirski
2019-04-19 21:19 ` Jethro Beekman
2019-04-19 21:31 ` Andy Lutomirski
2019-04-19 21:35 ` Jethro Beekman
2019-04-19 21:38 ` Thomas Gleixner
2019-04-19 21:56 ` Jethro Beekman
2019-04-20 5:42 ` Thomas Gleixner
2019-04-20 16:02 ` Dr. Greg
2019-04-22 15:01 ` Sean Christopherson
2019-04-22 16:24 ` Dr. Greg
2019-04-22 16:48 ` Sean Christopherson
2019-04-22 16:55 ` Linus Torvalds
2019-04-22 17:17 ` Sean Christopherson
2019-04-23 9:11 ` Dr. Greg
2019-04-22 16:26 ` Andy Lutomirski
2019-04-23 21:15 ` Jethro Beekman
2019-05-10 17:23 ` Xing, Cedric
2019-05-10 17:37 ` Jethro Beekman
2019-05-10 17:54 ` Dave Hansen
2019-05-10 18:04 ` Jethro Beekman
2019-05-10 18:56 ` Xing, Cedric
2019-05-10 19:04 ` Jethro Beekman
2019-05-10 19:22 ` Andy Lutomirski
2019-05-11 1:06 ` Xing, Cedric
2019-05-14 15:08 ` Andy Lutomirski
2019-05-15 8:31 ` Jarkko Sakkinen
[not found] ` <20190513102926.GD8743@linux.intel.com>
2019-05-14 10:43 ` Jarkko Sakkinen
2019-05-14 15:13 ` Andy Lutomirski
2019-05-14 20:45 ` Sean Christopherson
2019-05-14 21:27 ` Andy Lutomirski
2019-05-14 22:28 ` Xing, Cedric
2019-05-15 1:30 ` Sean Christopherson
2019-05-15 18:27 ` SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Andy Lutomirski
2019-05-15 19:58 ` James Morris
2019-05-15 20:35 ` Andy Lutomirski
2019-05-15 22:46 ` James Morris
2019-05-15 23:13 ` Andy Lutomirski
2019-05-16 3:03 ` Xing, Cedric
2019-05-16 4:40 ` Andy Lutomirski
2019-05-16 22:23 ` Xing, Cedric
2019-05-17 0:35 ` Andy Lutomirski
2019-05-17 1:06 ` Xing, Cedric
2019-05-17 1:21 ` Andy Lutomirski
2019-05-17 16:05 ` Sean Christopherson
2019-05-17 13:53 ` Stephen Smalley
2019-05-17 15:09 ` Sean Christopherson
2019-05-17 16:20 ` Stephen Smalley
2019-05-17 16:24 ` Andy Lutomirski
2019-05-17 16:37 ` Stephen Smalley
2019-05-17 17:12 ` Andy Lutomirski
2019-05-17 18:05 ` Stephen Smalley
2019-05-17 19:20 ` Stephen Smalley
2019-05-17 19:28 ` Sean Christopherson
2019-05-17 20:09 ` Stephen Smalley
2019-05-17 20:14 ` Andy Lutomirski
2019-05-17 20:34 ` Stephen Smalley
2019-05-17 21:36 ` Sean Christopherson
2019-05-17 17:29 ` Sean Christopherson
2019-05-17 17:42 ` Stephen Smalley
2019-05-17 17:50 ` Sean Christopherson
2019-05-17 18:16 ` Stephen Smalley
2019-05-17 17:43 ` Andy Lutomirski
2019-05-17 17:55 ` Sean Christopherson
2019-05-17 18:04 ` Linus Torvalds
2019-05-17 18:21 ` Sean Christopherson
2019-05-17 18:33 ` Linus Torvalds
2019-05-17 18:52 ` Sean Christopherson
2019-05-17 18:53 ` Andy Lutomirski
2019-05-16 7:24 ` James Morris
2019-05-16 21:00 ` Andy Lutomirski
2019-05-20 9:38 ` Dr. Greg
2019-05-15 21:38 ` Sean Christopherson
2019-05-16 1:19 ` Haitao Huang
2019-05-16 5:16 ` Jarkko Sakkinen
2019-05-16 21:02 ` Andy Lutomirski
2019-05-16 22:45 ` Sean Christopherson
2019-05-16 23:29 ` Xing, Cedric
2019-05-20 11:29 ` Jarkko Sakkinen
2019-05-20 11:33 ` Jarkko Sakkinen
2019-05-17 0:03 ` Sean Christopherson
2019-05-17 0:26 ` Andy Lutomirski
2019-05-17 15:41 ` Sean Christopherson
2019-05-20 11:42 ` Jarkko Sakkinen
2019-05-20 11:41 ` Jarkko Sakkinen
2019-05-21 15:19 ` Jarkko Sakkinen
2019-05-21 15:24 ` Jethro Beekman
2019-05-22 13:10 ` Jarkko Sakkinen
2019-05-21 15:51 ` Sean Christopherson
2019-05-22 13:20 ` Jarkko Sakkinen
2019-05-22 13:22 ` Jarkko Sakkinen
2019-05-22 13:56 ` Stephen Smalley
2019-05-22 15:38 ` Sean Christopherson
2019-05-22 22:42 ` Andy Lutomirski
2019-05-23 2:35 ` Sean Christopherson
2019-05-23 10:26 ` Jarkko Sakkinen
2019-05-23 14:17 ` Sean Christopherson
2019-05-23 15:38 ` Andy Lutomirski
2019-05-23 23:40 ` Sean Christopherson
2019-05-24 1:17 ` Andy Lutomirski
2019-05-24 7:24 ` Xing, Cedric
2019-05-24 15:41 ` Stephen Smalley
2019-05-24 16:57 ` Xing, Cedric [this message]
2019-05-24 17:42 ` Sean Christopherson
2019-05-24 17:54 ` Andy Lutomirski
2019-05-24 17:56 ` Sean Christopherson
2019-05-24 17:54 ` Sean Christopherson
2019-05-24 18:34 ` Xing, Cedric
2019-05-24 19:13 ` Sean Christopherson
2019-05-24 19:30 ` Andy Lutomirski
2019-05-24 20:42 ` Xing, Cedric
2019-05-24 21:11 ` Sean Christopherson
2019-05-24 19:37 ` Andy Lutomirski
2019-05-24 20:03 ` Sean Christopherson
2019-05-24 20:58 ` Xing, Cedric
2019-05-24 21:27 ` Andy Lutomirski
2019-05-24 22:41 ` Sean Christopherson
2019-05-24 23:42 ` Andy Lutomirski
2019-05-25 22:40 ` Xing, Cedric
2019-05-26 0:57 ` Andy Lutomirski
2019-05-26 6:09 ` Xing, Cedric
2019-05-28 20:24 ` Sean Christopherson
2019-05-28 20:48 ` Andy Lutomirski
2019-05-28 21:41 ` Sean Christopherson
2019-05-30 5:38 ` Xing, Cedric
2019-05-30 17:21 ` Sean Christopherson
2019-05-29 14:08 ` Stephen Smalley
2019-05-30 6:12 ` Xing, Cedric
2019-05-30 14:22 ` Stephen Smalley
2019-05-30 14:31 ` Andy Lutomirski
2019-05-30 15:04 ` Stephen Smalley
2019-05-30 16:14 ` Andy Lutomirski
2019-05-30 18:01 ` Sean Christopherson
2019-05-30 19:20 ` Andy Lutomirski
2019-05-30 21:16 ` Sean Christopherson
2019-05-30 21:23 ` Andy Lutomirski
2019-05-30 21:36 ` Sean Christopherson
2019-06-03 9:12 ` Dr. Greg
2019-06-03 21:08 ` Jarkko Sakkinen
2019-05-30 21:48 ` Xing, Cedric
2019-05-30 22:24 ` Sean Christopherson
2019-06-03 21:05 ` Jarkko Sakkinen
2019-06-03 20:54 ` Jarkko Sakkinen
2019-06-03 21:23 ` Sean Christopherson
2019-06-04 11:39 ` Jarkko Sakkinen
2019-06-03 21:37 ` Andy Lutomirski
2019-06-03 20:47 ` Jarkko Sakkinen
2019-06-03 20:43 ` Jarkko Sakkinen
2019-05-25 17:31 ` Dr. Greg
2019-05-24 16:43 ` Andy Lutomirski
2019-05-24 17:07 ` Sean Christopherson
2019-05-24 17:51 ` Andy Lutomirski
2019-05-24 14:44 ` Stephen Smalley
2019-05-27 13:48 ` Jarkko Sakkinen
2019-05-23 19:58 ` Sean Christopherson
2019-05-27 13:34 ` Jarkko Sakkinen
2019-05-27 13:38 ` Jarkko Sakkinen
2019-05-23 8:10 ` Jarkko Sakkinen
2019-05-23 8:23 ` Jarkko Sakkinen
2019-05-20 11:36 ` Jarkko Sakkinen
2019-05-15 10:35 ` [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-05-15 11:00 ` Jarkko Sakkinen
2019-05-15 14:27 ` Andy Lutomirski
2019-05-16 5:07 ` Jarkko Sakkinen
2019-05-16 6:51 ` Jarkko Sakkinen
2019-05-16 7:02 ` Jarkko Sakkinen
2019-05-15 13:21 ` Sean Christopherson
2019-05-16 5:01 ` Jarkko Sakkinen
2019-05-15 8:49 ` Jarkko Sakkinen
2019-05-15 9:58 ` Jarkko Sakkinen
2019-05-14 14:33 ` Haitao Huang
2019-05-14 15:17 ` Andy Lutomirski
2019-05-14 15:30 ` Haitao Huang
2019-05-14 20:45 ` Andy Lutomirski
2019-05-14 21:08 ` Haitao Huang
2019-05-14 21:58 ` Xing, Cedric
2019-05-15 5:15 ` Haitao Huang
2019-05-10 18:44 ` Xing, Cedric
2019-04-19 21:34 ` Thomas Gleixner
2019-04-19 21:05 ` Jethro Beekman
2019-04-18 18:07 ` Andy Lutomirski
2019-04-22 20:42 ` [RFC PATCH v1 0/3] An alternative __vdso_sgx_enter_enclave() to allow enclave/host parameter passing using untrusted stack Cedric Xing
2019-04-22 22:05 ` Sean Christopherson
2019-04-23 0:37 ` Cedric Xing
2019-04-24 6:26 ` [RFC PATCH v2 " Cedric Xing
2019-07-10 11:17 ` Jarkko Sakkinen
2019-07-10 18:08 ` Xing, Cedric
2019-07-10 22:46 ` Jarkko Sakkinen
2019-07-10 22:54 ` Xing, Cedric
2019-07-11 9:36 ` Jarkko Sakkinen
2019-07-11 19:49 ` Xing, Cedric
2019-07-10 23:15 ` Jarkko Sakkinen
2019-07-10 23:37 ` Xing, Cedric
2019-07-11 9:38 ` Jarkko Sakkinen
2019-07-11 15:50 ` Sean Christopherson
2019-07-11 17:59 ` Jarkko Sakkinen
2019-07-11 19:51 ` Xing, Cedric
2019-07-11 4:21 ` [RFC PATCH v3 0/3] x86/sgx: Amend vDSO API to allow enclave/host parameter passing on " Cedric Xing
2019-07-12 3:28 ` Jarkko Sakkinen
2019-07-13 6:51 ` [RFC PATCH v4 " Cedric Xing
2019-07-13 6:51 ` [RFC PATCH v4 1/3] selftests/x86/sgx: Fix Makefile for SGX selftest Cedric Xing
2019-07-13 15:10 ` Jarkko Sakkinen
2019-07-13 15:15 ` Jarkko Sakkinen
2019-07-13 17:29 ` Xing, Cedric
2019-07-14 14:53 ` Jarkko Sakkinen
2019-07-13 6:51 ` [RFC PATCH v4 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-07-13 15:04 ` Jarkko Sakkinen
2019-07-13 15:06 ` Jarkko Sakkinen
2019-07-13 6:51 ` [RFC PATCH v4 3/3] selftests/x86/sgx: Augment SGX selftest to test vDSO API Cedric Xing
2019-07-13 15:21 ` Jarkko Sakkinen
2019-07-13 17:20 ` Xing, Cedric
2019-07-14 14:40 ` Jarkko Sakkinen
2019-07-14 14:47 ` Jarkko Sakkinen
2019-07-17 21:57 ` Xing, Cedric
2019-07-11 4:21 ` [RFC PATCH v3 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-07-11 4:21 ` [RFC PATCH v3 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-07-11 9:50 ` Jarkko Sakkinen
2019-07-11 9:53 ` Jarkko Sakkinen
2019-07-11 15:42 ` Sean Christopherson
2019-07-11 17:55 ` Jarkko Sakkinen
2019-07-11 17:58 ` Sean Christopherson
2019-07-12 3:16 ` Jarkko Sakkinen
2019-07-13 7:00 ` Xing, Cedric
2019-07-11 4:21 ` [RFC PATCH v3 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-04-24 6:26 ` [RFC PATCH v2 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-07-12 3:19 ` Jarkko Sakkinen
2019-07-13 6:58 ` Xing, Cedric
2019-04-24 6:26 ` [RFC PATCH v2 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-04-24 19:04 ` Sean Christopherson
2019-04-25 23:31 ` Xing, Cedric
2019-04-26 21:00 ` Sean Christopherson
2019-05-02 8:28 ` Jarkko Sakkinen
2019-04-24 6:26 ` [RFC PATCH v2 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-07-12 3:25 ` Jarkko Sakkinen
2019-07-13 7:03 ` Xing, Cedric
2019-04-22 20:42 ` [RFC PATCH v1 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-04-23 0:37 ` Cedric Xing
2019-04-22 20:42 ` [RFC PATCH v1 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-04-22 22:26 ` Sean Christopherson
2019-04-23 0:37 ` Cedric Xing
2019-04-23 1:25 ` Andy Lutomirski
2019-04-24 17:56 ` Xing, Cedric
2019-04-23 19:26 ` Sean Christopherson
2019-04-23 19:44 ` Andy Lutomirski
2019-04-22 20:42 ` [RFC PATCH v1 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-04-23 0:37 ` Cedric Xing
2019-04-23 1:29 ` Andy Lutomirski
2019-04-23 1:48 ` Sean Christopherson
2019-04-23 18:59 ` Sean Christopherson
2019-04-23 19:07 ` Andy Lutomirski
2019-04-23 20:11 ` Sean Christopherson
2019-04-23 11:56 ` [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-04-23 16:52 ` Andy Lutomirski
2019-04-24 12:17 ` Jarkko Sakkinen
2019-05-08 13:45 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=960B34DE67B9E140824F1DCDEC400C0F654E8D1E@ORSMSX116.amr.corp.intel.com \
--to=cedric.xing@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=eparis@parisplace.org \
--cc=greg@enjellic.com \
--cc=haitao.huang@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=jmorris@namei.org \
--cc=josh@joshtriplett.org \
--cc=kai.huang@intel.com \
--cc=kai.svahn@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=paul@paul-moore.com \
--cc=rientjes@google.com \
--cc=sds@tycho.nsa.gov \
--cc=sean.j.christopherson@intel.com \
--cc=selinux@vger.kernel.org \
--cc=serge.ayoun@intel.com \
--cc=serge@hallyn.com \
--cc=shay.katz-zamir@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).