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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,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 DC7F5C43382 for ; Wed, 26 Sep 2018 17:35:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 99B1D214DC for ; Wed, 26 Sep 2018 17:35:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99B1D214DC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=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 S1728410AbeIZXt1 (ORCPT ); Wed, 26 Sep 2018 19:49:27 -0400 Received: from mga14.intel.com ([192.55.52.115]:24845 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727205AbeIZXt1 (ORCPT ); Wed, 26 Sep 2018 19:49:27 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 10:35:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,307,1534834800"; d="scan'208";a="77491656" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.55]) by orsmga006.jf.intel.com with ESMTP; 26 Sep 2018 10:35:16 -0700 Date: Wed, 26 Sep 2018 10:35:16 -0700 From: Sean Christopherson To: Andy Lutomirski Cc: Jarkko Sakkinen , X86 ML , Platform Driver , Dave Hansen , 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: <20180926173516.GA10920@linux.intel.com> References: <20180925130845.9962-1-jarkko.sakkinen@linux.intel.com> <20180925130845.9962-10-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote: > Minor nit: > > On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen > wrote: > > > > From: Sean Christopherson > > > > > by (c) as the kernel doesn't really have any other reasonable option, > > e.g. we could kill the task or panic, but neither is warranted. > > Not killing the task is quite nice, but... > > > + /* > > + * Access is blocked by the Enclave Page Cache Map (EPCM), > > + * i.e. the access is allowed by the PTE but not the EPCM. > > + * This usually happens when the EPCM is yanked out from > > + * under us, e.g. by hardware after a suspend/resume cycle. > > + * In any case, there is nothing that can be done by the > > + * kernel to resolve the fault (short of killing the task). > > Maybe s/killing the task/sending a signal/? My intent was to document that, unlike all other page faults, the kernel can't fix the source of the fault even if it were omniscient. How about this? With formatting changes since it's long-winded... /* * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the * access is allowed by the PTE but not the EPCM. This usually happens * when the EPCM is yanked out from under us, e.g. by hardware after a * suspend/resume cycle. In any case, software, i.e. the kernel, can't * fix the source of the fault as the EPCM can't be directly modified * by software. Handle the fault as an access error in order to signal * userspace, e.g. so that userspace can rebuild their enclave(s), even * though userspace may not have actually violated access permissions. */ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com ([192.55.52.115]:24845 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727205AbeIZXt1 (ORCPT ); Wed, 26 Sep 2018 19:49:27 -0400 Date: Wed, 26 Sep 2018 10:35:16 -0700 From: Sean Christopherson To: Andy Lutomirski CC: Jarkko Sakkinen , X86 ML , Platform Driver , "Dave Hansen" , , , "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: <20180926173516.GA10920@linux.intel.com> References: <20180925130845.9962-1-jarkko.sakkinen@linux.intel.com> <20180925130845.9962-10-jarkko.sakkinen@linux.intel.com> Content-Type: text/plain; charset="us-ascii" In-Reply-To: Sender: List-ID: Return-Path: linux-sgx-owner@vger.kernel.org MIME-Version: 1.0 On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote: > Minor nit: > > On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen > wrote: > > > > From: Sean Christopherson > > > > > by (c) as the kernel doesn't really have any other reasonable option, > > e.g. we could kill the task or panic, but neither is warranted. > > Not killing the task is quite nice, but... > > > + /* > > + * Access is blocked by the Enclave Page Cache Map (EPCM), > > + * i.e. the access is allowed by the PTE but not the EPCM. > > + * This usually happens when the EPCM is yanked out from > > + * under us, e.g. by hardware after a suspend/resume cycle. > > + * In any case, there is nothing that can be done by the > > + * kernel to resolve the fault (short of killing the task). > > Maybe s/killing the task/sending a signal/? My intent was to document that, unlike all other page faults, the kernel can't fix the source of the fault even if it were omniscient. How about this? With formatting changes since it's long-winded... /* * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the * access is allowed by the PTE but not the EPCM. This usually happens * when the EPCM is yanked out from under us, e.g. by hardware after a * suspend/resume cycle. In any case, software, i.e. the kernel, can't * fix the source of the fault as the EPCM can't be directly modified * by software. Handle the fault as an access error in order to signal * userspace, e.g. so that userspace can rebuild their enclave(s), even * though userspace may not have actually violated access permissions. */