linux-kernel - Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180927153952.GA13225@linux.intel.com>
Date:   Thu, 27 Sep 2018 18:39:52 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        nhorman@...hat.com, npmccallum@...hat.com,
        "Ayoun, Serge" <serge.ayoun@...el.com>, shay.katz-zamir@...el.com,
        linux-sgx@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs
 w/ PF_SGX

On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote:
> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
> >> 	This flag is 1 if the exception is unrelated to paging and
> >> 	resulted from violation of SGX-specific access-control
> >> 	requirements. ... such a violation can occur only if there
> >> 	is no ordinary page fault...
> >>
> >> This is pretty important.  It means that *none* of the other
> >> paging-related stuff that we're doing applies.
> >>
> >> We also need to clarify how this can happen.  Is it through something
> >> than an app does, or is it solely when the hardware does something under
> >> the covers, like suspend/resume.
> > When you change page permissions lets say with mprotect after the and
> > try to do an invalid access according to the EPCM permissions this can
> > happen.
> 
> So, there are pages that are non-executable, non-readable, or
> non-writable both via the page tables and via underlying SGX
> permissions.  Then, we allow an mprotect() and a later access will
> result in one of these SGX faults?

The permissions are intersection of PTE and EPCM permissions.

EPCM permissions are part of the enclave measurement. For SGX1 they are
static. For SGX2 they can be changed with EMODPR/EACCEPT protocol (i.e.
measurement can be updated after enclave initialization).

> What permissions are these, exactly?  Is it even a good idea to let that
> mprotect() go through in the first place?

You define RWX for each page when you do EADD.

> Either way, it sounds like we have some new conditions to spell out in
> that comment.

Agreed.

/Jarkko