From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754078AbbL2Xs3 (ORCPT ); Tue, 29 Dec 2015 18:48:29 -0500 Received: from mga14.intel.com ([192.55.52.115]:5816 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753869AbbL2Xs0 (ORCPT ); Tue, 29 Dec 2015 18:48:26 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,497,1444719600"; d="scan'208";a="717172492" Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Linus Torvalds 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> Cc: Andy Lutomirski , "H. Peter Anvin" , Oleg Nesterov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Brian Gerst , "linux-kernel@vger.kernel.org" , Christoph Hellwig From: Dave Hansen Message-ID: <56831BC9.6030408@linux.intel.com> Date: Tue, 29 Dec 2015 15:48:25 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/18/2015 01: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? Right now, all I plan to do is make it a one-way trip: if a process does a prot=PROT_EXEC mapping, we dedicate a key local to that process, and it gets 14 usable keys. If it doesn't use prot=PROT_EXEC, then it gets 15 usable keys. > 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. The one constant I've heard from the folks that are going to use this is that 15 keys is not enough. That's why I'm hesitant to remove _any_ more. > 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. Having a dedicated or static key for execute-only doesn't really change this code. We just have one extra step to go look in the mm->context and see which pkey (if any) is assigned to be execute-only in the fault code. > (b) for much more efficient PAGEALLOC_DEBUG for kernel mappings. The current hardware only applies the keys on _PAGE_USER mappings, so we can't use it for kernel mappings.