Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751563AbbLRW3J (ORCPT ); Fri, 18 Dec 2015 17:29:09 -0500 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34094 "EHLO mail-ob0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990AbbLRW3H (ORCPT ); Fri, 18 Dec 2015 17:29:07 -0500 MIME-Version: 1.0 In-Reply-To: References: <56736BD1.5080700@linux.intel.com> <5673750B.606@linux.intel.com> <567453AF.5060808@linux.intel.com> <56746774.8000707@linux.intel.com> <567476CC.8080805@linux.intel.com> From: Andy Lutomirski Date: Fri, 18 Dec 2015 14:28:45 -0800 Message-ID: Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Linus Torvalds Cc: Dave Hansen , "H. Peter Anvin" , Oleg Nesterov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Brian Gerst , "linux-kernel@vger.kernel.org" , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2984 Lines: 71 On Fri, Dec 18, 2015 at 1:45 PM, Linus Torvalds wrote: > On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen > wrote: >> >> But, if we are picking out an execute-only pkey more dynamically, we've >> got to keep the default value for the entire process somewhere. > > How dynamic do we want to make this, though? > > I haven't looked at the details, and perhaps more importantly, I don't > know what exactly are the requirements you've gotten from the people > who are expected to actually use this. > > I think we might want to hardcode a couple of keys as "kernel > reserved". And I'd rather reserve them up-front than have some user > program be unhappy later when we want to use them. > > I guess we want to leave key #0 for "normal page", so my suggesting to > use that for the execute-only was probably misguided. > > But I do think we might want to have that "no read access" as a real > fixed key too, because I think the kernel itself would want to use it: > > (a) to make sure that it gets the right fault when user space passes > in a execute-only address to a system call. > > (b) for much more efficient PAGEALLOC_DEBUG for kernel mappings. > > so I do think that we'd want to reserve two of the 16 keys up front. > > Would it be ok for the expected users to have those keys simply be > fixed? With key 0 being used for all default pages, and key 1 being > used for all execute-only pages? And then defaulting PKRU to 4, > disallowing access to that key #1? > > I could imagine that some kernel person would want to use even more > keys, but I think two fixed keys are kind of the minimal we'd want to > use. I imagine we'd reserve key 0 for normal page and key 1 for deny-read. Let me be a bit more concrete about what I'm suggesting: We'd have thread_struct.baseline_pkru. It would start with key 0 allowing all access and key 1 denying reads. We'd have a syscall like set_protection_key that could allocate unused keys and change the values of keys that have been allocated. Those changes would be reflected in baseline_pkru. Changes to keys 0 and 1 in baseline_pkru would not be allowed. Signal delivery would load baseline_pkru into the PKRU register. Signal restore would restore PKRU to its previous value. WRPKRU would, of course, override baseline_pkru, but it wouldn't change baseline_pkru. The set_protection_key syscall would modify *both* real PKRU and baseline_pkru. Apps that don't want to use the baseline_pkru mechanism could use syscalls to claim ownership of protection keys but then manage them purely with WRPKRU directly. We could optionally disallow mprotect_key on keys that weren't allocated in advance. Does that seem sane? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/