From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 004D6C43382 for ; Thu, 27 Sep 2018 15:40:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2BDF216FA for ; Thu, 27 Sep 2018 15:40:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A2BDF216FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727767AbeI0V6s (ORCPT ); Thu, 27 Sep 2018 17:58:48 -0400 Received: from mga12.intel.com ([192.55.52.136]:51310 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727262AbeI0V6s (ORCPT ); Thu, 27 Sep 2018 17:58:48 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 08:39:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,311,1534834800"; d="scan'208";a="93898656" Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.69]) by fmsmga001.fm.intel.com with ESMTP; 27 Sep 2018 08:39:52 -0700 Date: Thu, 27 Sep 2018 18:39:52 +0300 From: Jarkko Sakkinen To: Dave Hansen 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 Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX Message-ID: <20180927153952.GA13225@linux.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 27 Sep 2018 18:39:52 +0300 From: Jarkko Sakkinen To: Dave Hansen CC: Andy Lutomirski , Sean Christopherson , Andy Lutomirski , X86 ML , Platform Driver , , , "Ayoun, Serge" , , , Andy Shevchenko , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , LKML Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX Message-ID: <20180927153952.GA13225@linux.intel.com> 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> Content-Type: text/plain; charset="us-ascii" In-Reply-To: Return-Path: jarkko.sakkinen@linux.intel.com MIME-Version: 1.0 List-ID: 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