From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752414AbbLUXEa (ORCPT ); Mon, 21 Dec 2015 18:04:30 -0500 Received: from mga03.intel.com ([134.134.136.65]:44730 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbbLUXE3 (ORCPT ); Mon, 21 Dec 2015 18:04:29 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,461,1444719600"; d="scan'208";a="846102715" Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Andy Lutomirski , 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: "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: <5678856A.5020509@linux.intel.com> Date: Mon, 21 Dec 2015 15:04:10 -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 02:28 PM, Andy Lutomirski wrote: ... >> 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. Are you sure thread_struct is the right place for this? I think of signal handlers as a process-wide thing, and it seems a bit goofy if we have the PKRU value in a signal handler depend on the PKRU of the thread that got interrupted. > 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. FWIW, I think we can do this without *actually* dedicating key 1 to execute-only. But that's a side issue. > Signal delivery would load baseline_pkru into the PKRU register. > Signal restore would restore PKRU to its previous value. Do you really mean "its previous value" or are you OK with the existing behavior which restores PKRU from the XSAVE buffer in the sigcontext? > 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. How about this: We make baseline_pkru a process-wide baseline and store it in mm->context. That way, no matter which thread gets interrupted for a signal, they see consistent values. We only write to it when an app _specifically_ asks for it to be updated with a special flag to sys_pkey_set(). When an app uses the execute-only support, we implicitly set the read-disable bit in baseline_pkru for the execute-only pkey.