From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Wed, 16 May 2018 13:52:44 -0700 Message-ID: <20180516205244.GB5479@ram.oc3035372033.ibm.com> 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> Reply-To: Ram Pai Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> Content-Disposition: inline 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: Florian Weimer Cc: linux-arch , Linux-MM , Linux API , X86 ML , Dave Hansen , linux-x86_64@vger.kernel.org, Andy Lutomirski , linuxppc-dev List-Id: linux-api@vger.kernel.org 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. RP From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40346 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751155AbeEPUwz (ORCPT ); Wed, 16 May 2018 16:52:55 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4GKifWi054175 for ; Wed, 16 May 2018 16:52:55 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j0ux4gajs-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 May 2018 16:52:55 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 May 2018 21:52:52 +0100 Date: Wed, 16 May 2018 13:52:44 -0700 From: Ram Pai Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Reply-To: Ram Pai 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> MIME-Version: 1.0 In-Reply-To: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> Message-ID: <20180516205244.GB5479@ram.oc3035372033.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline Sender: linux-arch-owner@vger.kernel.org List-ID: To: Florian Weimer Cc: Andy Lutomirski , Dave Hansen , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxppc-dev Message-ID: <20180516205244.Y9Vn834KUD5ggfMY_51rJYs6I7uF2hOJR1yPF8m5siU@z> 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. RP