From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Wed, 16 May 2018 13:54:54 -0700 Message-ID: References: <20180503021058.GA5670@ram.oc3035372033.ibm.com> <927c8325-4c98-d7af-b921-6aafcf8fe992@redhat.com> <314e1a48-db94-9b37-8793-a95a2082c9e2@redhat.com> <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> <20180516205244.GB5479@ram.oc3035372033.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180516205244.GB5479@ram.oc3035372033.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: linuxram@us.ibm.com Cc: Florian Weimer , linux-arch , Linux-MM , Linux API , X86 ML , Dave Hansen , linux-x86_64@vger.kernel.org, Andrew Lutomirski , linuxppc-dev List-Id: linux-api@vger.kernel.org On Wed, May 16, 2018 at 1:52 PM Ram Pai wrote: > On Mon, May 14, 2018 at 02:01:23PM +0200, Florian Weimer wrote: > > On 05/09/2018 04:41 PM, Andy Lutomirski wrote: > > >Hmm. I can get on board with the idea that fork() / clone() / > > >pthread_create() are all just special cases of the idea that the thread > > >that*calls* them should have the right pkey values, and the latter is > > >already busted given our inability to asynchronously propagate the new mode > > >in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point. > > > > Ram, any suggestions for implementing this on POWER? > I suspect the changes will go in > restore_user_regs() and save_user_regs(). These are the functions > that save and restore register state before entry and exit into/from > a signal handler. > > > > >One thing we could do, though: the current initual state on process > > >creation is all access blocked on all keys. We could change it so that > > >half the keys are fully blocked and half are read-only. Then we could add > > >a PKEY_ALLOC_STRICT or similar that allocates a key with the correct > > >initial state*and* does the setsignal thing. If there are no keys left > > >with the correct initial state, then it fails. > > > > The initial PKRU value can currently be configured by the system > > administrator. I fear this approach has too many moving parts to be > > viable. > Sounds like on x86 keys can go active in signal-handler > without any explicit allocation request by the application. This is not > the case on power. Is that API requirement? Hope not. On x86, signals are currently delivered with all keys locked all the way down (except for the magic one we use to emulate no-read access). I would hesitate to change this for existing applications. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:51004 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbeEPUzI (ORCPT ); Wed, 16 May 2018 16:55:08 -0400 Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A9E462083F for ; Wed, 16 May 2018 20:55:07 +0000 (UTC) Received: by mail-wr0-f176.google.com with SMTP id o4-v6so3365469wrm.0 for ; Wed, 16 May 2018 13:55:07 -0700 (PDT) MIME-Version: 1.0 References: <20180503021058.GA5670@ram.oc3035372033.ibm.com> <927c8325-4c98-d7af-b921-6aafcf8fe992@redhat.com> <314e1a48-db94-9b37-8793-a95a2082c9e2@redhat.com> <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> <20180516205244.GB5479@ram.oc3035372033.ibm.com> In-Reply-To: <20180516205244.GB5479@ram.oc3035372033.ibm.com> From: Andy Lutomirski Date: Wed, 16 May 2018 13:54:54 -0700 Message-ID: Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: linuxram@us.ibm.com Cc: Florian Weimer , Andrew Lutomirski , Dave Hansen , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxppc-dev Message-ID: <20180516205454.tUmpRxfqRMeMsg-hZ-x8Cxg1vJlLRCNmtoYE6CPoyYY@z> On Wed, May 16, 2018 at 1:52 PM Ram Pai wrote: > On Mon, May 14, 2018 at 02:01:23PM +0200, Florian Weimer wrote: > > On 05/09/2018 04:41 PM, Andy Lutomirski wrote: > > >Hmm. I can get on board with the idea that fork() / clone() / > > >pthread_create() are all just special cases of the idea that the thread > > >that*calls* them should have the right pkey values, and the latter is > > >already busted given our inability to asynchronously propagate the new mode > > >in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point. > > > > Ram, any suggestions for implementing this on POWER? > I suspect the changes will go in > restore_user_regs() and save_user_regs(). These are the functions > that save and restore register state before entry and exit into/from > a signal handler. > > > > >One thing we could do, though: the current initual state on process > > >creation is all access blocked on all keys. We could change it so that > > >half the keys are fully blocked and half are read-only. Then we could add > > >a PKEY_ALLOC_STRICT or similar that allocates a key with the correct > > >initial state*and* does the setsignal thing. If there are no keys left > > >with the correct initial state, then it fails. > > > > The initial PKRU value can currently be configured by the system > > administrator. I fear this approach has too many moving parts to be > > viable. > Sounds like on x86 keys can go active in signal-handler > without any explicit allocation request by the application. This is not > the case on power. Is that API requirement? Hope not. On x86, signals are currently delivered with all keys locked all the way down (except for the magic one we use to emulate no-read access). I would hesitate to change this for existing applications.