lkml.org 
[lkml]   [2019]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits
    On Tue, Jun 11, 2019 at 05:09:28PM -0700, Andy Lutomirski wrote:
    >
    > On Jun 10, 2019, at 3:28 PM, Xing, Cedric <cedric.xing@intel.com> wrote:
    >
    > >> From: Andy Lutomirski [mailto:luto@kernel.org]
    > >> Sent: Monday, June 10, 2019 12:15 PM
    > >> This seems like an odd workflow. Shouldn't the #PF return back to
    > >> untrusted userspace so that the untrusted user code can make its own
    > >> decision as to whether it wants to EAUG a page there as opposed to, say,
    > >> killing the enclave or waiting to keep resource usage under control?
    > >
    > > This may seem odd to some at the first glance. But if you can think of how
    > > static heap (pre-allocated by EADD before EINIT) works, the load parses the
    > > "metadata" coming with the enclave to decide the address/size of the heap,
    > > EADDs it, and calls it done. In the case of "dynamic" heap (allocated
    > > dynamically by EAUG after EINIT), the same thing applies - the loader
    > > determines the range of the heap, tells the SGX module about it, and calls
    > > it done. Everything else is the between the enclave and the SGX module.
    > >
    > > In practice, untrusted code usually doesn't know much about enclaves, just
    > > like it doesn't know much about the shared objects loaded into its address
    > > space either. Without the necessary knowledge, untrusted code usually just
    > > does what it is told (via o-calls, or return value from e-calls), without
    > > judging that's right or wrong.
    > >
    > > When it comes to #PF like what I described, of course a signal could be
    > > sent to the untrusted code but what would it do then? Usually it'd just
    > > come back asking for a page at the fault address. So we figured it'd be
    > > more efficient to just have the kernel EAUG at #PF.
    > >
    > > Please don't get me wrong though, as I'm not dictating what the s/w flow
    > > shall be. It's just going to be a choice offered to user mode. And that
    > > choice was planned to be offered via mprotect() - i.e. a writable vma
    > > causes kernel to EAUG while a non-writable vma will result in a signal
    > > (then the user mode could decide whether to EAUG). The key point is
    > > flexibility - as we want to allow all reasonable s/w flows instead of
    > > dictating one over others. We had similar discussions on vDSO API before.
    > > And I think you accepted my approach because of its flexibility. Am I
    > > right?
    >
    > As long as user code can turn this off, I have no real objection. But it
    > might make sense to have it be more explicit — have an ioctl set up a range
    > as “EAUG-on-demand”.

    This was part of the motivation behind changing SGX_IOC_ENCLAVE_ADD_PAGE
    to SGX_IOC_ENCLAVE_ADD_REGION and adding a @flags parameter. E.g. adding
    support for "EAUG-on-demand" regions would just be a new flag.

    > But this is all currently irrelevant. We can argue about it when the patches
    > show up. :)

    \
     
     \ /
      Last update: 2019-06-12 16:34    [W:2.768 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site