From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Date: Wed, 21 Nov 2018 00:55:18 +0200 Message-ID: <20181120225518.GE8391@linux.intel.com> References: <20181118071548.GA4795@linux.intel.com> <20181119160204.GD13298@linux.intel.com> <20181120101133.GA7319@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Florian Weimer , Linux API , Jann Horn , Linus Torvalds , X86 ML , linux-arch , LKML , Peter Zijlstra , Rich Felker , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov List-Id: linux-arch.vger.kernel.org On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote: > What is "#GP with EPCM"? We certainly don't want to react to #UD in A typo. Meant #PF with PF_SGX set i.e. EPCM conflict. > general by mucking with some regs and retrying -- that will infinite > loop and confuse everyone. I'm not even 100% convinced that decoding > the insn stream is useful -- AEP can point to something that isn't > ENCLU. In my return-to-AEP approach to whole point was not to do any decoding but instead have something else always in the AEP handler than just ENCLU. No instruction decoding. No RIP manipulation. > IOW the kernel needs to know *when* to apply this special behavior. > Sadly there is no bit in the exception frame that says "came from > SGX". /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com ([192.55.52.136]:8522 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725887AbeKUJ1F (ORCPT ); Wed, 21 Nov 2018 04:27:05 -0500 Date: Wed, 21 Nov 2018 00:55:18 +0200 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Message-ID: <20181120225518.GE8391@linux.intel.com> References: <20181118071548.GA4795@linux.intel.com> <20181119160204.GD13298@linux.intel.com> <20181120101133.GA7319@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Florian Weimer , Linux API , Jann Horn , Linus Torvalds , X86 ML , linux-arch , LKML , Peter Zijlstra , Rich Felker , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov Message-ID: <20181120225518.qEmDA1PmjYRQhMUkW_-boyf3mlcuAu4drrq-5p8OvpQ@z> On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote: > What is "#GP with EPCM"? We certainly don't want to react to #UD in A typo. Meant #PF with PF_SGX set i.e. EPCM conflict. > general by mucking with some regs and retrying -- that will infinite > loop and confuse everyone. I'm not even 100% convinced that decoding > the insn stream is useful -- AEP can point to something that isn't > ENCLU. In my return-to-AEP approach to whole point was not to do any decoding but instead have something else always in the AEP handler than just ENCLU. No instruction decoding. No RIP manipulation. > IOW the kernel needs to know *when* to apply this special behavior. > Sadly there is no bit in the exception frame that says "came from > SGX". /Jarkko