From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by kanga.kvack.org (Postfix) with ESMTP id EBA306B0003 for ; Fri, 8 Jun 2018 09:51:07 -0400 (EDT) Received: by mail-qt0-f200.google.com with SMTP id k7-v6so12302062qtm.1 for ; Fri, 08 Jun 2018 06:51:07 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id m100-v6si3942380qkh.104.2018.06.08.06.51.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 06:51:07 -0700 (PDT) Subject: Re: pkeys on POWER: Access rights not reset on execve References: <20180520060425.GL5479@ram.oc3035372033.ibm.com> <20180520191115.GM5479@ram.oc3035372033.ibm.com> <20180603201832.GA10109@ram.oc3035372033.ibm.com> <4e53b91f-80a7-816a-3e9b-56d7be7cd092@redhat.com> <20180604140135.GA10088@ram.oc3035372033.ibm.com> <20180604190229.GB10088@ram.oc3035372033.ibm.com> <30040030-1aa2-623b-beec-dd1ceb3eb9a7@redhat.com> <20180608023441.GA5573@ram.oc3035372033.ibm.com> <2858a8eb-c9b5-42ce-5cfc-74a4b3ad6aa9@redhat.com> <20180608121551.3c151e0c@naga.suse.cz> <20180608145413.393fa245@kitsune.suse.cz> <20180608154954.327c19be@kitsune.suse.cz> From: Florian Weimer Message-ID: <05e7d0f4-0955-11ce-06c5-1c2ab1153499@redhat.com> Date: Fri, 8 Jun 2018 15:51:03 +0200 MIME-Version: 1.0 In-Reply-To: <20180608154954.327c19be@kitsune.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: =?UTF-8?Q?Michal_Such=c3=a1nek?= Cc: Linux-MM , Ram Pai , linuxppc-dev , Andy Lutomirski , Dave Hansen On 06/08/2018 03:49 PM, Michal SuchA!nek wrote: > On Fri, 8 Jun 2018 14:57:06 +0200 > Florian Weimer wrote: > >> On 06/08/2018 02:54 PM, Michal SuchA!nek wrote: >>> On Fri, 8 Jun 2018 12:44:53 +0200 >>> Florian Weimer wrote: >>> >>>> On 06/08/2018 12:15 PM, Michal SuchA!nek wrote: >>>>> On Fri, 8 Jun 2018 07:53:51 +0200 >>>>> Florian Weimer wrote: >>>>> >>>>>> On 06/08/2018 04:34 AM, Ram Pai wrote: >>>>>>>> >>>>>>>> So the remaining question at this point is whether the Intel >>>>>>>> behavior (default-deny instead of default-allow) is >>>>>>>> preferable. >>>>>>> >>>>>>> Florian, remind me what behavior needs to fixed? >>>>>> >>>>>> See the other thread. The Intel register equivalent to the AMR >>>>>> by default disallows access to yet-unallocated keys, so that >>>>>> threads which are created before key allocation do not magically >>>>>> gain access to a key allocated by another thread. >>>>>> >>>>> >>>>> That does not make any sense. The threads share the address space >>>>> so they should also share the keys. >>>>> >>>>> Or in other words the keys are supposed to be acceleration of >>>>> mprotect() so if mprotect() magically gives access to threads that >>>>> did not call it so should pkey functions. If they cannot do that >>>>> then they fail the primary purpose. >>>> >>>> That's not how protection keys work. The access rights are >>>> thread-specific, so that you can change them locally, without >>>> synchronization and expensive inter-node communication. >>>> >>> >>> And the association of a key with part of the address space is >>> thread-local as well? >> >> No, that part is still per-process. > > So as said above it does not make sense to make keys per-thread. The keys are still global, but the access rights are per-thread and have to be for reliability reasons. Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 412P2Q2qrMzDrp0 for ; Fri, 8 Jun 2018 23:51:09 +1000 (AEST) Subject: Re: pkeys on POWER: Access rights not reset on execve To: =?UTF-8?Q?Michal_Such=c3=a1nek?= Cc: Linux-MM , Ram Pai , linuxppc-dev , Andy Lutomirski , Dave Hansen References: <20180520060425.GL5479@ram.oc3035372033.ibm.com> <20180520191115.GM5479@ram.oc3035372033.ibm.com> <20180603201832.GA10109@ram.oc3035372033.ibm.com> <4e53b91f-80a7-816a-3e9b-56d7be7cd092@redhat.com> <20180604140135.GA10088@ram.oc3035372033.ibm.com> <20180604190229.GB10088@ram.oc3035372033.ibm.com> <30040030-1aa2-623b-beec-dd1ceb3eb9a7@redhat.com> <20180608023441.GA5573@ram.oc3035372033.ibm.com> <2858a8eb-c9b5-42ce-5cfc-74a4b3ad6aa9@redhat.com> <20180608121551.3c151e0c@naga.suse.cz> <20180608145413.393fa245@kitsune.suse.cz> <20180608154954.327c19be@kitsune.suse.cz> From: Florian Weimer Message-ID: <05e7d0f4-0955-11ce-06c5-1c2ab1153499@redhat.com> Date: Fri, 8 Jun 2018 15:51:03 +0200 MIME-Version: 1.0 In-Reply-To: <20180608154954.327c19be@kitsune.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/08/2018 03:49 PM, Michal Suchánek wrote: > On Fri, 8 Jun 2018 14:57:06 +0200 > Florian Weimer wrote: > >> On 06/08/2018 02:54 PM, Michal Suchánek wrote: >>> On Fri, 8 Jun 2018 12:44:53 +0200 >>> Florian Weimer wrote: >>> >>>> On 06/08/2018 12:15 PM, Michal Suchánek wrote: >>>>> On Fri, 8 Jun 2018 07:53:51 +0200 >>>>> Florian Weimer wrote: >>>>> >>>>>> On 06/08/2018 04:34 AM, Ram Pai wrote: >>>>>>>> >>>>>>>> So the remaining question at this point is whether the Intel >>>>>>>> behavior (default-deny instead of default-allow) is >>>>>>>> preferable. >>>>>>> >>>>>>> Florian, remind me what behavior needs to fixed? >>>>>> >>>>>> See the other thread. The Intel register equivalent to the AMR >>>>>> by default disallows access to yet-unallocated keys, so that >>>>>> threads which are created before key allocation do not magically >>>>>> gain access to a key allocated by another thread. >>>>>> >>>>> >>>>> That does not make any sense. The threads share the address space >>>>> so they should also share the keys. >>>>> >>>>> Or in other words the keys are supposed to be acceleration of >>>>> mprotect() so if mprotect() magically gives access to threads that >>>>> did not call it so should pkey functions. If they cannot do that >>>>> then they fail the primary purpose. >>>> >>>> That's not how protection keys work. The access rights are >>>> thread-specific, so that you can change them locally, without >>>> synchronization and expensive inter-node communication. >>>> >>> >>> And the association of a key with part of the address space is >>> thread-local as well? >> >> No, that part is still per-process. > > So as said above it does not make sense to make keys per-thread. The keys are still global, but the access rights are per-thread and have to be for reliability reasons. Thanks, Florian