linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: "Xing, Cedric" <cedric.xing@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	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: Tue, 28 May 2019 13:48:02 -0700	[thread overview]
Message-ID: <CALCETrWTXCb1jru1G5G3sOp5AV8iYUtrffiSxE-5gotXtrZD-g@mail.gmail.com> (raw)
In-Reply-To: <20190528202407.GB13158@linux.intel.com>

On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote:
> > > From: Andy Lutomirski [mailto:luto@kernel.org]
> > > Sent: Saturday, May 25, 2019 5:58 PM
> > >
> > > On Sat, May 25, 2019 at 3:40 PM Xing, Cedric <cedric.xing@intel.com> wrote:
> > > >
> > > > If we think of EADD as a way of mmap()'ing an enclave file into memory,
> > > > would this
> > > security_enclave_load() be the same as
> > > security_mmap_file(source_vma->vm_file, maxperm, MAP_PRIVATE), except that
> > > the target is now EPC instead of regular pages?
> > >
> > > Hmm, that's clever.  Although it seems plausible that an LSM would want to
> > > allow RX or RWX of a given file page but only in the context of an approved
> > > enclave, so I think it should still be its own hook.
> >
> > What do you mean by "in the context of an approved enclave"? EPC pages are
> > *inaccessible* to any software until after EINIT. So it would never be a
> > security concern to EADD a page with wrong permissions as long as the enclave
> > would be denied eventually by LSM at EINIT.
> >
> > But I acknowledge the difference between loading a page into regular memory
> > vs. into EPC. So it's beneficial to have a separate hook, which if not
> > hooked, would pass through to security_mmap_file() by default?
>
> Mapping the enclave will still go through security_mmap_file(), the extra
> security_enclave_load() hook allows the mmap() to use PROT_NONE.
>
> > > If it's going to be in an arbitrary file, then I think the signature needs to be more like:
> > >
> > > int security_enclave_init(struct vm_area_struct *sigstruct_vma, loff_t sigstruct_offset,
> > > const sgx_sigstruct *sigstruct);
> > >
> > > So that the LSM still has the opportunity to base its decision on the contents of the
> > > SIGSTRUCT.  Actually, we need that change regardless.
> >
> > Wouldn't the pair of { sigstruct_vma, sigstruct_offset } be the same as just
> > a pointer, because the VMA could be looked up using the pointer and the
> > offset would then be (pointer - vma->vm_start)?
>
> VMA has vm_file, e.g. the .sigstruct file labeled by LSMs.  That being
> said, why does the LSM need the VMA?  E.g. why not this?
>
>   int security_enclave_init(struct file *file, struct sgx_sigstruct *sigstruct);
>
> > > > Loosely speaking, an enclave (including initial contents of all of its pages and their
> > > permissions) and its MRENCLAVE are a 1-to-1 correspondence (given the collision resistant
> > > property of SHA-2). So only one is needed for a decision, and either one would lead to the
> > > same decision. So I don't see anything making any sense here.
> > > >
> > > > Theoretically speaking, if LSM can make a decision at EINIT by means of
> > > security_enclave_load(), then security_enclave_load() is never needed.
> > > >
> > > > In practice, I support keeping both because security_enclave_load() can only approve an
> > > enumerable set while security_enclave_load() can approve a non-enumerable set of enclaves.
> > > Moreover, in order to determine the validity of a MRENCLAVE (as in development of a policy
> > > or in creation of a white/black list), system admins will need the audit log produced by
> > > security_enclave_load().
> > >
> > > I'm confused.  Things like MRSIGNER aren't known until the SIGSTRUCT shows
> > > up.  Also, security_enclave_load() provides no protection against loading a
> > > mishmash of two different enclave files.  I see security_enclave_init() as
> > > "verify this SIGSTRUCT against your policy on who may sign enclaves and/or
> > > grant EXECMOD depending on SIGSTRUCT" and security_enclave_load() as
> > > "implement your EXECMOD / EXECUTE / WRITE / whatever policy and possibly
> > > check enclave files for some label."
> >
> > Sorry for the confusion. I was saying the same thing except that the decision
> > of security_enclave_load() doesn't have to depend on SIGSTRUCT. Given your
> > prototype of security_enclave_load(), I think we are on the same page. I made
> > the above comment to object to the idea of "require that the sigstruct be
> > supplied before any EADD operations so that the maxperm decisions can depend
> > on the sigstruct".
>
> Except that having the sigstruct allows using the sigstruct as the proxy
> for the enclave.  I think the last big disconnect is that Andy and I want
> to tie everything to an enclave-specific file, i.e. sigstruct, while you
> are proposing labeling /dev/sgx/enclave.  If someone wants to cram several
> sigstructs into a single file, so be it, but using /dev/sgx/enclave means
> users can't do per-enclave permissions, period.
>
> What is your objection to working on the sigstruct?
>
> > > > > > Passing both would allow tying EXECMOD to /dev/sgx/enclave as
> > > > > > Cedric wanted (without having to play games and pass
> > > > > > /dev/sgx/enclave to security_enclave_load()), but I don't think
> > > > > > there's anything fundamentally broken with using .sigstruct for
> > > > > > EXECMOD.  It requires more verbose labeling, but that's not a bad thing.
> > > > >
> > > > > The benefit of putting it on .sigstruct is that it can be per-enclave.
> > > > >
> > > > > As I understand it from Fedora packaging, the way this works on
> > > > > distros is generally that a package will include some files and
> > > > > their associated labels, and, if the package needs EXECMOD, then the
> > > > > files are labeled with EXECMOD and the author of the relevant code might get a dirty
> > > look.
> > > > >
> > > > > This could translate to the author of an exclave that needs RWX
> > > > > regions getting a dirty look without leaking this permission into other enclaves.
> > > > >
> > > > > (In my opinion, the dirty looks are actually the best security
> > > > > benefit of the entire concept of LSMs making RWX difficult.  A
> > > > > sufficiently creative attacker can almost always bypass W^X
> > > > > restrictions once they’ve pwned you, but W^X makes it harder to pwn
> > > > > you in the first place, and SELinux makes it really obvious when
> > > > > packaging a program that doesn’t respect W^X.  The upshot is that a
> > > > > lot of programs got fixed.)
> > > >
> > > > I'm lost here. Dynamically linked enclaves, if running on SGX2, would need RW->RX, i.e.
> > > FILE__EXECMOD on /dev/sgx/enclave. But they never need RWX, i.e. PROCESS__EXECMEM.
> > >
> > > Hmm.  If we want to make this distinction, we need something a big richer
> > > than my proposed callbacks.  A check of the actual mprotect() / mmap()
> > > permissions would also be needed.  Specifically, allowing MAXPERM=RWX
> > > wouldn't imply that PROT_WRITE | PROT_EXEC is allowed.
>
> Actually, I think we do have everything we need from an LSM perspective.
> LSMs just need to understand that sgx_enclave_load() with a NULL vma
> implies a transition from RW.  For example, SELinux would interpret
> sgx_enclave_load(NULL, RX) as requiring FILE__EXECMOD.

You lost me here.  What operation triggers this callback?  And
wouldn't sgx_enclave_load(NULL, RX) sometimes be a transition from RO
or just some fresh executable zero bytes?

>
> As Cedric mentioned earlier, the host process doesn't necessarily know
> which pages will end up RW vs RX, i.e. sgx_enclave_load(NULL, RX)
> already has to be invoked at runtime, and when that happens, the kernel
> can take the opportunity to change the VMAs from MAY_RW to MAY_RX.
>
> For simplicity in the kernel and clarity in userspace, it makes sense to
> require an explicit ioctl() to add the to-be-EAUG'd range.  That just
> leaves us wanting an ioctl() to set the post-EACCEPT{COPY} permissions.
>
> E.g.:
>
>     ioctl(<prefix>_ADD_REGION, { NULL }) /* NULL == EAUG, MAY_RW */
>
>     mprotect(addr, size, RW);
>     ...
>
>     EACCEPTCOPY -> EAUG /* page fault handler */
>
>     ioctl(<prefix>_ACTIVATE_REGION, { addr, size, RX}) /* MAY_RX */
>
>     mprotect(addr, size, RX);

In the maxperm model, this mprotect() will fail unless MAXPERM
contains RX, which could only happen if MAXPERM=RWX.  So, regardless
of how it's actually mapped to SELinux policy, MAXPERM=RWX is
functionally like EXECMOD and actual RWX PTEs are functionally like
EXECMEM.

>
>     ...
>
> And making ACTIVATE_REGION a single-shot per page eliminates the need for
> the MAXPERMS concept (see below).
>
> > If we keep only one MAXPERM, wouldn't this be the current behavior of
> > mmap()/mprotect()?
> >
> > To be a bit more clear, system admin sets MAXPERM upper bound in the form of
> > FILE__{READ|WRITE|EXECUTE|EXECMOD} of /dev/sgx/enclave. Then for a
> > process/enclave, if what it requires falls below what's allowed on
> > /dev/sgx/enclave, then everything will just work. Otherwise, it fails in the
> > form of -EPERM returned from mmap()/mprotect(). Please note that MAXPERM here
> > applies to "runtime" permissions, while "initial" permissions are taken care
> > of by security_enclave_{load|init}. "initial" permissions could be more
> > permissive than "runtime" permissions, e.g., RX is still required for initial
> > code pages even though system admins could disable dynamically loaded code
> > pages by *not* giving FILE__{EXECUTE|EXECMOD}. Therefore, the "initial"
> > mapping would still have to be done by the driver (to bypass LSM), either via
> > a new ioctl or as part of IOC_EINIT.
>
> Aha!
>
> Starting with Cedric's assertion that initial permissions can be taken
> directly from SECINFO:
>
>   - Initial permissions for *EADD* pages are explicitly handled via
>     sgx_enclave_load() with the exact SECINFO permissions.
>
>   - Initial permissions for *EAUG* are unconditionally RW.  EACCEPTCOPY
>     requires the target EPC page to be RW, and EACCEPT with RO is useless.
>
>   - Runtime permissions break down as follows:
>       R   - N/A, subset of RW (EAUG)
>       W   - N/A, subset of RW (EAUG) and x86 paging can't do W
>       X   - N/A, subset of RX (x86 paging can't do XO)

Sure it can!  You just have a hypervisor that maps a PA bit to EPT
no-read.  Then you can use that PA bit to suppress read.  Also, Linux
already abuses PKRU to simulate XO, although that won't work for
enclaves.

>       RW  - Handled by EAUG LSM hook (uses RW unconditionally)
>       WX  - N/A, subset of RWX (x86 paging can't do WX)
>       RX  - Handled by ACTIVATE_REGION
>       RWX - Handled by ACTIVATE_REGION
>
> In other words, if we define the SGX -> LSM calls as follows (minus the
> file pointer and other params for brevity):
>
>   - <prefix>_ACTIVATE_REGION(vma, perms) -> sgx_enclave_load(NULL, perms)
>
>   - <prefix>_ADD_REGION(vma) -> sgx_enclave_load(vma, SECINFO.perms)
>
>   - <prefix>_ADD_REGION(NULL) -> sgx_enclave_load(NULL, RW)
>
> then SGX and LSMs have all the information and hooks needed.  The catch
> is that the LSM semantics of sgx_enclave_load(..., RW) would need to be
> different than normal shared memory, e.g. FILE__WRITE should *not* be
> required, but that's ok since it's an SGX specific hook.  And if for some
> reason an LSM wanted to gate access to EAUG *without* FILE__EXECMOD, it'd
> have the necessary information to do so.
>
> The userspace changes are fairly minimal:
>
>   - For SGX1, use PROT_NONE for the initial mmap() and refactor ADD_PAGE
>     to ADD_REGION.
>
>   - For SGX2, do an explicit ADD_REGION on the ranges to be EAUG'd, and an
>     ACTIVATE_REGION to make a region RX or R (no extra ioctl() required to
>     keep RW permissions).
>
> Because ACTIVATE_REGION can only be done once per page, to do *abitrary*
> mprotect() transitions, userspace would need to set the added/activated
> permissions to be a superset of the transitions, e.g. RW -> RX would
> require RWX, but that's a non-issue.
>

I may be misunderstanding or just be biased to my own proposal, but
this seems potentially more complicated and less flexible than the
MAXPERM model.  One of the main things that made me come up with
MAXPERM is that I wanted to avoid any complicated PTE/VMA modification
or runtime changes.  So, with MAXPERM, we still need to track the
MAXPERM bits per page, but we don't ever need to *change* them or to
worry about what is or is not mapped anywhere at any given time.  With
ACTIVATE_REGION, don't we need to make sure that we don't have a
second VMA pointing at the same pages?  Or am I just confused?

>   - For SGX1 it's a nop since it's impossible to change the EPCM
>     permissions, i.e. the page would need to be RWX regardless.

I may still be missing something, but, for SGX1, it's possible at
least in principle for the enclave to request, via ocall or similar,
that the untrusted runtime do mprotect().  It's not even such a bad
idea.  Honestly, enclaves *shouldn't* have anything actually writable
and executable at once because the enclaves don't want to be easily
exploited.

>
>   - For SGX2, userspace can suck it up and request RWX to do completely
>     arbitrary transitions (working as intended), or the kernel can support
>     trimming (removing) pages from an enclave, which would allow userspace
>     to do "arbitrary" transitions by first removing the page.

  reply	other threads:[~2019-05-28 20:48 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
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 [this message]
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=CALCETrWTXCb1jru1G5G3sOp5AV8iYUtrffiSxE-5gotXtrZD-g@mail.gmail.com \
    --to=luto@kernel.org \
    --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=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).