lkml.org 
[lkml]   [2020]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct
    On Fri, Nov 06, 2020 at 09:54:19AM -0800, Dave Hansen wrote:

    Good morning, I hope the weekend is going well for everyone, beautiful
    weather out here in West-Cental Minnesota.

    > On 11/6/20 9:43 AM, Dr. Greg wrote:
    > > In light of this, given the decision by the driver authors to not
    > > fully equip the driver with EDMM support, the mprotect protection
    > > requirements are straight forward and minimalistic. All that is
    > > needed is a binary valued variable, set on the command-line, that
    > > either allows or denies anonymous code execution by an enclave,
    > > ie. access to page protection changes after initialization.

    > To that, I say NAK. We need more flexibility than a boot-time-fixed,
    > system-wide switch.

    To be clear, I wasn't referring to a global yes/no option in the code
    that implements the mprotect callout method in the
    vm_operations_struct. I was referring to the implementation of the
    hook in the SGX driver code.

    In all of these discussions there hasn't been a refutation of my point
    that the only reason this hook is needed is to stop the potential for
    anonymous code execution on SGX2 capable hardware. So we will assume,
    that while unspoken, this is the rationale for the hook.

    If you are NAK'ing a global enable/disable in the driver code, I think
    there needs to be a discussion of why the driver, in its current
    state, needs anything other then a yes/no decision on mprotect after
    enclave initialization is complete.

    At this point in time the driver has no intention of supporting EDMM,
    so the simple belt-and-suspenders approach is to deny mprotect on
    enclave virtual memory after initialization. Absent mprotect, the
    hardware is perfectly capable of enforcing page permissions that are
    only consistent with the initial mapping of the enclave.

    If and when EDMM is implemented there might be a rationale for per
    page mprotect interrogation. I won't waste people's time here but I
    believe a cogent arguement can be made that there is little utility,
    even under EDMM, of making per page permission decisions rather then a
    'yes/no' decision by the platform owner as to whether or not they want
    to allow anonymous code execution.

    Hopefully all of this is a useful clarification.

    Have a good weekend.

    Dr. Greg

    As always,
    Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive
    Enjellic Systems Development, LLC IOT platforms and edge devices.
    4206 N. 19th Ave.
    Fargo, ND 58102
    PH: 701-281-1686 EMAIL: greg@enjellic.com
    ------------------------------------------------------------------------------
    "If you ever teach a yodeling class, probably the hardest thing is to
    keep the students from just trying to yodel right off. You see, we build
    to that."
    -- Jack Handey
    Deep Thoughts

    \
     
     \ /
      Last update: 2020-11-07 16:10    [W:2.123 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site