From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Date: Thu, 8 Nov 2018 17:04:05 +0200 Message-ID: <20181108150405.GB14072@linux.intel.com> References: <1541541565.8854.13.camel@intel.com> <7FF4802E-FBC5-4E6D-A8F6-8A65114F18C7@amacapital.net> <20181106233515.GB11101@linux.intel.com> <20181107000235.GC11101@linux.intel.com> <20181107153452.GB22972@linux.intel.com> <20181107190114.GA26603@linux.intel.com> <662fa2c8-c9a8-b2a8-ee8b-92a8a89c0630@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <662fa2c8-c9a8-b2a8-ee8b-92a8a89c0630@intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Dave Hansen Cc: Sean Christopherson , Andy Lutomirski , Jann Horn , Linus Torvalds , Rich Felker , Dave Hansen , 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 List-Id: linux-arch.vger.kernel.org On Wed, Nov 07, 2018 at 12:56:58PM -0800, Dave Hansen wrote: > On 11/7/18 11:01 AM, Sean Christopherson wrote: > > Going off comments in similar code related to UMIP, we'd need to figure > > out how to handle protection keys. > > There are two options: > 1. Don't depend on the userspace mapping. Do get_user_pages() to find > the instruction in the kernel direct map, and use that. > 2. Do a WRPKRU that allows read access, do the read, then put PKRU back. > This is a pain because of preemption and all that jazz. > > Right now, we just let the prefetch instruction detection fail if you > mark it unreadable with pkeys. Tough cookies, basically. But, that's > just the kernel being nice, but you need it for functionality, so it's > tougher. I would go with one because it is the stable way to do it and we are 100% sure to not conflict with pk's. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com ([192.55.52.115]:13569 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726469AbeKIAkN (ORCPT ); Thu, 8 Nov 2018 19:40:13 -0500 Date: Thu, 8 Nov 2018 17:04:05 +0200 From: Jarkko Sakkinen Subject: Re: RFC: userspace exception fixups Message-ID: <20181108150405.GB14072@linux.intel.com> References: <1541541565.8854.13.camel@intel.com> <7FF4802E-FBC5-4E6D-A8F6-8A65114F18C7@amacapital.net> <20181106233515.GB11101@linux.intel.com> <20181107000235.GC11101@linux.intel.com> <20181107153452.GB22972@linux.intel.com> <20181107190114.GA26603@linux.intel.com> <662fa2c8-c9a8-b2a8-ee8b-92a8a89c0630@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <662fa2c8-c9a8-b2a8-ee8b-92a8a89c0630@intel.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Hansen Cc: Sean Christopherson , Andy Lutomirski , Jann Horn , Linus Torvalds , Rich Felker , Dave Hansen , 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: <20181108150405.9XvaqbYmPIey9NUzOjCBcQczem_khYzhJy5fjM-4Jn8@z> On Wed, Nov 07, 2018 at 12:56:58PM -0800, Dave Hansen wrote: > On 11/7/18 11:01 AM, Sean Christopherson wrote: > > Going off comments in similar code related to UMIP, we'd need to figure > > out how to handle protection keys. > > There are two options: > 1. Don't depend on the userspace mapping. Do get_user_pages() to find > the instruction in the kernel direct map, and use that. > 2. Do a WRPKRU that allows read access, do the read, then put PKRU back. > This is a pain because of preemption and all that jazz. > > Right now, we just let the prefetch instruction detection fail if you > mark it unreadable with pkeys. Tough cookies, basically. But, that's > just the kernel being nice, but you need it for functionality, so it's > tougher. I would go with one because it is the stable way to do it and we are 100% sure to not conflict with pk's. /Jarkko