From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Thu, 17 May 2018 12:09:36 +0200 Message-ID: <1a46685f-1ca7-d215-455c-c75254959684@redhat.com> References: <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> <20180516210745.GC5479@ram.oc3035372033.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180516210745.GC5479@ram.oc3035372033.ibm.com> Content-Language: en-US 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: Ram Pai , Andy Lutomirski Cc: linux-arch , Linux-MM , Linux API , X86 ML , Dave Hansen , linux-x86_64@vger.kernel.org, linuxppc-dev List-Id: linux-api@vger.kernel.org On 05/16/2018 11:07 PM, Ram Pai wrote: > what would change the key-permission-values enforced in signal-handler > context? Or can it never be changed, ones set through sys_pkey_alloc()? The access rights can only be set by pkey_alloc and are unchanged after that (so we do not have to discuss whether the signal handler access rights are per-thread or not). > I suppose key-permission-values change done in non-signal-handler context, > will not apply to those in signal-handler context. Correct, that is the plan. > Can the signal handler change the key-permission-values from the > signal-handler context? Yes, changes are possible. The access rights given to pkey_alloc only specify the initial access rights when the signal handler is entered. We need to decide if we should restore it on exit from the signal handler. There is also the matter of siglongjmp, which currently does not restore the current thread's access rights. In general, this might be difficult to implement because of the limited space in jmp_buf. Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751664AbeEQKJj (ORCPT ); Thu, 17 May 2018 06:09:39 -0400 Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics References: <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> <20180516210745.GC5479@ram.oc3035372033.ibm.com> From: Florian Weimer Message-ID: <1a46685f-1ca7-d215-455c-c75254959684@redhat.com> Date: Thu, 17 May 2018 12:09:36 +0200 MIME-Version: 1.0 In-Reply-To: <20180516210745.GC5479@ram.oc3035372033.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Ram Pai , Andy Lutomirski Cc: Dave Hansen , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxppc-dev Message-ID: <20180517100936.Wz3XURt1EDXc8Ehh5fnX4O3Y6gJdCNUEygw40mdRghQ@z> On 05/16/2018 11:07 PM, Ram Pai wrote: > what would change the key-permission-values enforced in signal-handler > context? Or can it never be changed, ones set through sys_pkey_alloc()? The access rights can only be set by pkey_alloc and are unchanged after that (so we do not have to discuss whether the signal handler access rights are per-thread or not). > I suppose key-permission-values change done in non-signal-handler context, > will not apply to those in signal-handler context. Correct, that is the plan. > Can the signal handler change the key-permission-values from the > signal-handler context? Yes, changes are possible. The access rights given to pkey_alloc only specify the initial access rights when the signal handler is entered. We need to decide if we should restore it on exit from the signal handler. There is also the matter of siglongjmp, which currently does not restore the current thread's access rights. In general, this might be difficult to implement because of the limited space in jmp_buf. Thanks, Florian