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:37:46 -0700 Message-ID: References: <57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net> <6286ba0a-7e09-b4ec-e31f-bd091f5940ff@redhat.com> <20180503021058.GA5670@ram.oc3035372033.ibm.com> <927c8325-4c98-d7af-b921-6aafcf8fe992@redhat.com> <314e1a48-db94-9b37-8793-a95a2082c9e2@redhat.com> <20180516203534.GA5479@ram.oc3035372033.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180516203534.GA5479@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:35 PM Ram Pai wrote: > On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote: > > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > >On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > > > >>On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > > >>>On Wed, May 2, 2018 at 7:11 PM Ram Pai wrote: > > >>> > > >>>>On Wed, May 02, 2018 at 09:23:49PM +0000, Andy Lutomirski wrote: > > >>>>> > > >>>>>>If I recall correctly, the POWER maintainer did express a strong > > >>>desire > > >>>>>>back then for (what is, I believe) their current semantics, which my > > >>>>>>PKEY_ALLOC_SIGNALINHERIT patch implements for x86, too. > > >>>>> > > >>>>>Ram, I really really don't like the POWER semantics. Can you give > > >some > > >>>>>justification for them? Does POWER at least have an atomic way for > > >>>>>userspace to modify just the key it wants to modify or, even better, > > >>>>>special load and store instructions to use alternate keys? > > >>> > > >>>>I wouldn't call it POWER semantics. The way I implemented it on power > > >>>>lead to the semantics, given that nothing was explicitly stated > > >>>>about how the semantics should work within a signal handler. > > >>> > > >>>I think that this is further evidence that we should introduce a new > > >>>pkey_alloc() mode and deprecate the old. To the extent possible, this > > >>>thing should work the same way on x86 and POWER. > > > > > >>Do you propose to change POWER or to change x86? > > > > > >Sorry for being slow to reply. I propose to introduce a new > > >PKEY_ALLOC_something variant on x86 and POWER and to make the behavior > > >match on both. > > > > So basically implement PKEY_ALLOC_SETSIGNAL for POWER, and keep the > > existing (different) behavior without the flag? > > > > Ram, would you be okay with that? Could you give me a hand if > > necessary? (I assume we have silicon in-house because it's a > > long-standing feature of the POWER platform which was simply dormant > > on Linux until now.) > Yes. I can help you with that. > So let me see if I understand the overall idea. > Application can allocate new keys through a new syscall > sys_pkey_alloc_1(flags, init_val, sig_init_val) > 'sig_init_val' is the permission-state of the key in signal context. > The kernel will set the permission of each keys to their > corresponding values when entering the signal handler and revert > on return from the signal handler. > just like init_val, sig_init_val also percolates to children threads. I was imagining it would be just pkey_alloc(SOME_NEW_FLAG, init_val); and the init val would be used for the current thread and for signal handlers. New threads would inherit their parents' values. The latter is certainly up for negotiation, but it's the simplest behavior, and it's not obvious to be that it's wrong. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:43616 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132AbeEPUiA (ORCPT ); Wed, 16 May 2018 16:38:00 -0400 Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 5D51E2083D for ; Wed, 16 May 2018 20:37:59 +0000 (UTC) Received: by mail-wm0-f46.google.com with SMTP id l1-v6so5007807wmb.2 for ; Wed, 16 May 2018 13:37:59 -0700 (PDT) MIME-Version: 1.0 References: <57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net> <6286ba0a-7e09-b4ec-e31f-bd091f5940ff@redhat.com> <20180503021058.GA5670@ram.oc3035372033.ibm.com> <927c8325-4c98-d7af-b921-6aafcf8fe992@redhat.com> <314e1a48-db94-9b37-8793-a95a2082c9e2@redhat.com> <20180516203534.GA5479@ram.oc3035372033.ibm.com> In-Reply-To: <20180516203534.GA5479@ram.oc3035372033.ibm.com> From: Andy Lutomirski Date: Wed, 16 May 2018 13:37:46 -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: <20180516203746.CaqXeyWRifvIRrpNDyPOEhn0dLZsbHQnW4MH7WRTJgk@z> On Wed, May 16, 2018 at 1:35 PM Ram Pai wrote: > On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote: > > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > >On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > > > >>On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > > >>>On Wed, May 2, 2018 at 7:11 PM Ram Pai wrote: > > >>> > > >>>>On Wed, May 02, 2018 at 09:23:49PM +0000, Andy Lutomirski wrote: > > >>>>> > > >>>>>>If I recall correctly, the POWER maintainer did express a strong > > >>>desire > > >>>>>>back then for (what is, I believe) their current semantics, which my > > >>>>>>PKEY_ALLOC_SIGNALINHERIT patch implements for x86, too. > > >>>>> > > >>>>>Ram, I really really don't like the POWER semantics. Can you give > > >some > > >>>>>justification for them? Does POWER at least have an atomic way for > > >>>>>userspace to modify just the key it wants to modify or, even better, > > >>>>>special load and store instructions to use alternate keys? > > >>> > > >>>>I wouldn't call it POWER semantics. The way I implemented it on power > > >>>>lead to the semantics, given that nothing was explicitly stated > > >>>>about how the semantics should work within a signal handler. > > >>> > > >>>I think that this is further evidence that we should introduce a new > > >>>pkey_alloc() mode and deprecate the old. To the extent possible, this > > >>>thing should work the same way on x86 and POWER. > > > > > >>Do you propose to change POWER or to change x86? > > > > > >Sorry for being slow to reply. I propose to introduce a new > > >PKEY_ALLOC_something variant on x86 and POWER and to make the behavior > > >match on both. > > > > So basically implement PKEY_ALLOC_SETSIGNAL for POWER, and keep the > > existing (different) behavior without the flag? > > > > Ram, would you be okay with that? Could you give me a hand if > > necessary? (I assume we have silicon in-house because it's a > > long-standing feature of the POWER platform which was simply dormant > > on Linux until now.) > Yes. I can help you with that. > So let me see if I understand the overall idea. > Application can allocate new keys through a new syscall > sys_pkey_alloc_1(flags, init_val, sig_init_val) > 'sig_init_val' is the permission-state of the key in signal context. > The kernel will set the permission of each keys to their > corresponding values when entering the signal handler and revert > on return from the signal handler. > just like init_val, sig_init_val also percolates to children threads. I was imagining it would be just pkey_alloc(SOME_NEW_FLAG, init_val); and the init val would be used for the current thread and for signal handlers. New threads would inherit their parents' values. The latter is certainly up for negotiation, but it's the simplest behavior, and it's not obvious to be that it's wrong. --Andy