From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Date: Sat, 3 Nov 2018 00:37:57 +0200 Message-ID: <20181102223757.GB24373@linux.intel.com> References: <20181101185225.GC5150@brightrain.aerifal.cx> <20181101193107.GE5150@brightrain.aerifal.cx> 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: Linus Torvalds , Rich Felker , Jann Horn , Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , 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 , Carlos List-Id: linux-arch.vger.kernel.org On Thu, Nov 01, 2018 at 04:22:55PM -0700, Andy Lutomirski wrote: > On Thu, Nov 1, 2018 at 2:24 PM Linus Torvalds > wrote: > > > > On Thu, Nov 1, 2018 at 12:31 PM Rich Felker wrote: > > > > > > See my other emails in this thread. You would register the *address* > > > (in TLS) of a function pointer object pointing to the handler, rather > > > than the function address of the handler. Then switching handler is > > > just a single store in userspace, no syscalls involved. > > > > Yes. > > > > And for just EENTER, maybe that's the right model. > > > > If we want to generalize it to other thread-synchronous faults, it > > needs way more information and a list of handlers, but if we limit the > > thing to _only_ EENTER getting an SGX fault, then a single "this is > > the fault handler" address is probably the right thing to do. > > It sounds like you're saying that the kernel should know, *before* > running any user fixup code, whether the fault in question is one that > wants a fixup. Sounds reasonable. > > I think it would be nice, but not absolutely necessary, if user code > didn't need to poke some value into TLS each time it ran a function > that had a fixup. With the poke-into-TLS approach, it looks a lot > like rseq, and rseq doesn't nest very nicely. I think we really want > this mechanism to Just Work. So we could maybe have a syscall that > associates a list of fixups with a given range of text addresses. We > might want the kernel to automatically zap the fixups when the text in > question is unmapped. If we would have a syscall to specify a list fixups that would do the job. Now essentially the only reason we require a vDSO is to implement a single fixup for EENTER. If this fixup stuff makes sense for other parts of the kernel, introducing a vDSO for EENTER means essentially adding ABI to the kernel that might possibly become legacy fast. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:61363 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726778AbeKCHrK (ORCPT ); Sat, 3 Nov 2018 03:47:10 -0400 Date: Sat, 3 Nov 2018 00:37:57 +0200 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Message-ID: <20181102223757.GB24373@linux.intel.com> References: <20181101185225.GC5150@brightrain.aerifal.cx> <20181101193107.GE5150@brightrain.aerifal.cx> 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: Linus Torvalds , Rich Felker , Jann Horn , Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , 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 , Carlos O'Donell , adhemerval.zanella@linaro.org Message-ID: <20181102223757.CsVVcAODgjU6uzg_AH43KHsLlsKdFxOzw_qJsQX5QL0@z> On Thu, Nov 01, 2018 at 04:22:55PM -0700, Andy Lutomirski wrote: > On Thu, Nov 1, 2018 at 2:24 PM Linus Torvalds > wrote: > > > > On Thu, Nov 1, 2018 at 12:31 PM Rich Felker wrote: > > > > > > See my other emails in this thread. You would register the *address* > > > (in TLS) of a function pointer object pointing to the handler, rather > > > than the function address of the handler. Then switching handler is > > > just a single store in userspace, no syscalls involved. > > > > Yes. > > > > And for just EENTER, maybe that's the right model. > > > > If we want to generalize it to other thread-synchronous faults, it > > needs way more information and a list of handlers, but if we limit the > > thing to _only_ EENTER getting an SGX fault, then a single "this is > > the fault handler" address is probably the right thing to do. > > It sounds like you're saying that the kernel should know, *before* > running any user fixup code, whether the fault in question is one that > wants a fixup. Sounds reasonable. > > I think it would be nice, but not absolutely necessary, if user code > didn't need to poke some value into TLS each time it ran a function > that had a fixup. With the poke-into-TLS approach, it looks a lot > like rseq, and rseq doesn't nest very nicely. I think we really want > this mechanism to Just Work. So we could maybe have a syscall that > associates a list of fixups with a given range of text addresses. We > might want the kernel to automatically zap the fixups when the text in > question is unmapped. If we would have a syscall to specify a list fixups that would do the job. Now essentially the only reason we require a vDSO is to implement a single fixup for EENTER. If this fixup stuff makes sense for other parts of the kernel, introducing a vDSO for EENTER means essentially adding ABI to the kernel that might possibly become legacy fast. /Jarkko