From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX Date: Thu, 27 Sep 2018 08:53:27 -0700 Message-ID: References: <20180925130845.9962-1-jarkko.sakkinen@linux.intel.com> <20180925130845.9962-10-jarkko.sakkinen@linux.intel.com> <20180926173516.GA10920@linux.intel.com> <2D60780F-ADB4-48A4-AB74-15683493D369@amacapital.net> <9835e288-ba98-2f9e-ac73-504db9512bb9@intel.com> <20180927134223.GA8242@linux.intel.com> <20180927153952.GA13225@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20180927153952.GA13225@linux.intel.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Jarkko Sakkinen Cc: Andy Lutomirski , Sean Christopherson , Andy Lutomirski , X86 ML , Platform Driver , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , LKML List-Id: platform-driver-x86.vger.kernel.org On 09/27/2018 08:39 AM, Jarkko Sakkinen wrote: > 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. Right, but this *fault* bit is not. > 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 does this all have to do with enclave measurement? >> 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. Are those permissions reflected into the VMAs mapping the enclave memory?