From: Vlastimil Babka <vbabka@suse.cz> To: Dave Hansen <dave@sr71.net>, linux-kernel@vger.kernel.org Cc: x86@kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, luto@kernel.org, mgorman@techsingularity.net, dave.hansen@linux.intel.com, arnd@arndb.de Subject: Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Date: Tue, 2 Aug 2016 10:20:41 +0200 [thread overview] Message-ID: <95491d2d-35cf-ebf9-a34e-0405def707e2@suse.cz> (raw) In-Reply-To: <579F6380.2070600@sr71.net> On 08/01/2016 04:58 PM, Dave Hansen wrote: > On 08/01/2016 07:42 AM, Vlastimil Babka wrote: >> On 07/29/2016 06:30 PM, Dave Hansen wrote: >>> This does not cause any practical problems with applications >>> using protection keys because we require them to specify initial >>> permissions for each key when it is allocated, which override the >>> restrictive default. >> >> Here you mean the init_access_rights parameter of pkey_alloc()? So will >> children of fork() after that pkey_alloc() inherit the new value or go >> default? > > Hi Vlastimil, > > Yes, exactly, the initial permissions are provided via pkey_alloc()'s > 'init_access_rights' argument. OK. I was a bit sceptical of that part of the syscall, as you removed other syscalls changing PKRU for the thread in kernel, so leaving this seemed odd. But it makes sense to me together with the restrictive default. > Do you mean fork() or clone()? In both cases, we actually copy the FPU > state from the parent, so children always inherit the state from their > parent which contains the permissions set by the parent's calls to > pkey_alloc(). I meant just fork() as I misunderstood the changelog in that clone() is different. Thanks for clarifying.
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz> To: Dave Hansen <dave@sr71.net>, linux-kernel@vger.kernel.org Cc: x86@kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, luto@kernel.org, mgorman@techsingularity.net, dave.hansen@linux.intel.com, arnd@arndb.de Subject: Re: [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Date: Tue, 2 Aug 2016 10:20:41 +0200 [thread overview] Message-ID: <95491d2d-35cf-ebf9-a34e-0405def707e2@suse.cz> (raw) In-Reply-To: <579F6380.2070600@sr71.net> On 08/01/2016 04:58 PM, Dave Hansen wrote: > On 08/01/2016 07:42 AM, Vlastimil Babka wrote: >> On 07/29/2016 06:30 PM, Dave Hansen wrote: >>> This does not cause any practical problems with applications >>> using protection keys because we require them to specify initial >>> permissions for each key when it is allocated, which override the >>> restrictive default. >> >> Here you mean the init_access_rights parameter of pkey_alloc()? So will >> children of fork() after that pkey_alloc() inherit the new value or go >> default? > > Hi Vlastimil, > > Yes, exactly, the initial permissions are provided via pkey_alloc()'s > 'init_access_rights' argument. OK. I was a bit sceptical of that part of the syscall, as you removed other syscalls changing PKRU for the thread in kernel, so leaving this seemed odd. But it makes sense to me together with the restrictive default. > Do you mean fork() or clone()? In both cases, we actually copy the FPU > state from the parent, so children always inherit the state from their > parent which contains the permissions set by the parent's calls to > pkey_alloc(). I meant just fork() as I misunderstood the changelog in that clone() is different. Thanks for clarifying. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-08-02 8:23 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-07-29 16:30 [PATCH 00/10] [v6] System Calls for Memory Protection Keys Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-07-29 16:30 ` [PATCH 01/10] x86, pkeys: add fault handling for PF_PK page fault bit Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:10 ` [tip:mm/pkeys] x86/pkeys: Add " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 02/10] mm: implement new pkey_mprotect() system call Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:11 ` [tip:mm/pkeys] mm: Implement " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 03/10] x86, pkeys: make mprotect_key() mask off additional vm_flags Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:11 ` [tip:mm/pkeys] x86/pkeys: Make " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 04/10] x86, pkeys: allocation/free syscalls Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:12 ` [tip:mm/pkeys] x86/pkeys: Allocation/free syscalls tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 05/10] x86: wire up protection keys system calls Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:12 ` [tip:mm/pkeys] x86: Wire " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 06/10] generic syscalls: wire up memory protection keys syscalls Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:12 ` [tip:mm/pkeys] generic syscalls: Wire " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 07/10] pkeys: add details of system call use to Documentation/ Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:13 ` [tip:mm/pkeys] pkeys: Add " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-07-29 17:29 ` Andy Lutomirski 2016-07-29 17:29 ` Andy Lutomirski 2016-07-29 17:50 ` Dave Hansen 2016-07-29 17:50 ` Dave Hansen 2016-07-29 19:44 ` Andy Lutomirski 2016-07-29 19:44 ` Andy Lutomirski 2016-08-01 14:42 ` Vlastimil Babka 2016-08-01 14:42 ` Vlastimil Babka 2016-08-01 14:58 ` Dave Hansen 2016-08-01 14:58 ` Dave Hansen 2016-08-02 8:20 ` Vlastimil Babka [this message] 2016-08-02 8:20 ` Vlastimil Babka 2016-09-09 11:13 ` [tip:mm/pkeys] x86/pkeys: Default " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 09/10] x86, pkeys: allow configuration of init_pkru Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-08-02 8:28 ` Vlastimil Babka 2016-08-02 8:28 ` Vlastimil Babka 2016-08-02 14:37 ` Dave Hansen 2016-08-02 14:37 ` Dave Hansen 2016-09-09 11:14 ` [tip:mm/pkeys] x86/pkeys: Allow " tip-bot for Dave Hansen 2016-07-29 16:30 ` [PATCH 10/10] x86, pkeys: add self-tests Dave Hansen 2016-07-29 16:30 ` Dave Hansen 2016-09-09 11:14 ` [tip:mm/pkeys] x86/pkeys: Add self-tests tip-bot for Dave Hansen 2016-08-08 23:18 [PATCH 00/10] [v6] System Calls for Memory Protection Keys Dave Hansen 2016-08-08 23:18 ` [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Dave Hansen 2016-08-08 23:18 ` Dave Hansen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=95491d2d-35cf-ebf9-a34e-0405def707e2@suse.cz \ --to=vbabka@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=dave.hansen@linux.intel.com \ --cc=dave@sr71.net \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=mgorman@techsingularity.net \ --cc=torvalds@linux-foundation.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.