From: Sean Christopherson <sean.j.christopherson@intel.com> To: "Xing, Cedric" <cedric.xing@intel.com> Cc: Stephen Smalley <sds@tycho.nsa.gov>, Andy Lutomirski <luto@kernel.org>, 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 12:13:44 -0700 Message-ID: <20190524191344.GD365@linux.intel.com> (raw) In-Reply-To: <960B34DE67B9E140824F1DCDEC400C0F654E8E1D@ORSMSX116.amr.corp.intel.com> On Fri, May 24, 2019 at 11:34:32AM -0700, Xing, Cedric wrote: > > From: linux-sgx-owner@vger.kernel.org [mailto:linux-sgx- > > owner@vger.kernel.org] On Behalf Of Sean Christopherson > > Sent: Friday, May 24, 2019 10:55 AM > > > > On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote: > > > Hmm, I've been thinking more about pulling permissions from the source > > > page. Conceptually I'm not sure we need to meet the same requirements as > > > non-enclave DSOs while the enclave is being built, i.e. do we really need > > > to force userspace to fully map the enclave in normal memory? > > > > > > Consider the Graphene scenario where it's building an enclave on the fly. > > > Pulling permissions from the source VMAs means Graphene has to map the > > > code pages of the enclave with X. This means Graphene will need EXEDMOD > > > (or EXECMEM if Graphene isn't careful). In a non-SGX scenario this makes > > > perfect sense since there is no way to verify the end result of RW->RX. > > > > > > But for SGX, assuming enclaves are whitelisted by their sigstruct (checked > > > at EINIT) and because page permissions affect sigstruct.MRENCLAVE, it *is* > > > possible to verify the resulting RX contents. E.g. for the purposes of > > > LSMs, can't we use the .sigstruct file as a proxy for the enclave and > > > require FILE__EXECUTE on the .sigstruct inode to map/run the enclave? > > > > > > Stephen, is my logic sound? > > > > > > > > > If so... > > > > > > - Require FILE__READ+FILE__EXECUTE on .sigstruct to mmap() the enclave. > > > > > > - Prevent userspace from mapping the enclave with permissions beyond the > > > original permissions of the enclave. This can be done by populating > > > VM_MAY{READ,WRITE,EXEC} from the SECINFO (same basic concept as Andy's > > > proposals). E.g. pre-EINIT, mmap() and mprotect() can only succeed > > > with PROT_NONE. > > > > > > - Require FILE__{READ,WRITE,EXECUTE} on /dev/sgx/enclave for simplicity, > > > or provide an alternate SGX_IOC_MPROTECT if we want to sidestep the > > > FILE__WRITE requirement. > > > > One more thought. EADD (and the equivalent SGX2 flow) could do > > security_mmap_file() with a NULL file on the SECINFO permissions, which > > would trigger PROCESS_EXECMEM if an enclave attempts to map a page RWX. > > If "initial permissions" for enclaves are less restrictive than shared > objects, then it'd become a backdoor for circumventing LSM when enclave > whitelisting is *not* in place. For example, an adversary may load a page, > which would otherwise never be executable, as an executable page in EPC. My point is that enclaves have different properties than shared objects. Normal LSM behavior with regard to executing files is to label files with e.g. FILE__EXECUTE. Because an enclave must be built to the exact specifications of .sigstruct, requring FILE__EXECUTE on the .sigstruct is effectively the same as requiring FILE__EXECUTE on the enclave itself. Addressing your scenario of loading an executable page in EPC, doing so would require one of the following: - Ability to install a .sigstruct with FILE__EXECUTE - PROCESS__EXECMEM - FILE__EXECMOD and SGX2 support > In the case a RWX page is needed, the calling process has to have a RWX page > serving as the source for EADD so PROCESS__EXECMEM will have been checked. > For SGX2, changing an EPC page to RWX is subject to FILE__EXECMEM on > /dev/sgx/enclave, which I see as a security benefit because it only affects > the enclave but not the whole process hosting it. There is no FILE__EXECMEM check, only PROCESS__EXECMEM and FILE__EXECMOD. I assume you're referring to the latter? I don't see a fundamental difference between having RWX in an enclave and RWX in normal memory, either way the process can execute arbitrary code, i.e. PROCESS__EXECMEM is appropriate. Yes, an enclave will #UD on certain instructions, but that's easily sidestepped by having a trampoline in the host (marked RX) and piping arbitrary code into the enclave. Or using EEXIT to do a bit of ROP. > > > No changes are required to LSMs, SGX1 has a single LSM touchpoint in > > its > > > mmap(), and I *think* the only required userspace change is to mmap() > > > PROT_NONE when allocating the enclave's virtual address range. > > I'm not sure I understand the motivation behind this proposal to decouple > initial EPC permissions from source pages. Pulling permissions from source pages means userspace needs to fully map the in normal memory, including marking pages executable. That exposes the loader to having executable pages in its address space that it has no intention of executing (outside of the enclave). And for Graphene, it means having to actively avoid PROCESS__EXECMEM, e.g. by using a dummy backing file to build the enclave instead of anon memory. > I don't think it a big deal to fully mmap() enclave files, which have to be > parsed by user mode anyway to determine various things including but not > limited to the size of heap(s), size and number of TCSs/stacks/TLS areas, and > the overall enclave size. So with PHDRs parsed, it's trivial to mmap() each > segment with permissions from its PHDR. > > > > As for Graphene, it doesn't need extra permissions to run its enclaves, > > > it just needs a way to install .sigstruct, which is a generic permissions > > > problem and not SGX specific. > > > > > > > > > For SGX2 maybe: > > > > > > - No additional requirements to map an EAUG'd page as RW page. Not > > > aligned with standard MAP_SHARED behavior, but we really don't want > > > to require FILE__WRITE, and thus allow writes to .sigstruct. > > > > > > - Require FILE__EXECMOD on the .sigstruct to map previously writable > > > page as executable (which indirectly includes all EAUG'd pages). > > > Wiring this up will be a little funky, but we again we don't want > > > to require FILE__WRITE on .sigstruct. > > > > > I'm lost. Why is EAUG tied to permissions on .sigstruct? Because for the purposes of LSM checks, .sigstruct is the enclave's backing file, and mapping a previously writable enclave page as exectuable is roughly equivalent to mapping a CoW'd page as exectuable.
next prev parent reply index 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 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 [this message] 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=20190524191344.GD365@linux.intel.com \ --to=sean.j.christopherson@intel.com \ --cc=akpm@linux-foundation.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bp@alien8.de \ --cc=cedric.xing@intel.com \ --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=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
Linux-Sgx Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \ linux-sgx@vger.kernel.org public-inbox-index linux-sgx Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx AGPL code for this site: git clone https://public-inbox.org/public-inbox.git