Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2595pxb; Mon, 31 Jan 2022 03:49:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPM1phSepHtTND/DISe2vmjOHM5+hXJo8a7gpaGXWzmcwQ+nQEnLFi8jlcyG7lzIKXVJT2 X-Received: by 2002:a17:902:dcc9:: with SMTP id t9mr19813849pll.15.1643629741244; Mon, 31 Jan 2022 03:49:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643629741; cv=none; d=google.com; s=arc-20160816; b=FZgemKoQwxJKeT4x15RTLCONS87Sk8ZJQ9mYZZw57VfJ58a6GjpB0NiVbczdAQCTFp UJBln3fAZXMtVGuicByIquW+MX8k+Jq6sONSHpM35nA5+JDY7hL/Dqq7xd4FIxmsumGh hYN7l0+Fz2/7el5IDV6MJBGZugBE25/5g2bq4RZDOZ1K/sOpdX3i0L1CVbcQ8NpDEgYW XDMscRJT5EUzv8P9ZpaglT9NcqzUNejQKzCXcfHmffdPisIPYTt6QGWTysqtL49JqVf/ VrumWOfk86v2E/bANwCPNKM2d5LxKVI/qDQDm+2fbx8Zj7KbtsOuzHyllKlfWvpff95E IfWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=qV3ZPlGJG4Azhfwnd96VfftVQEOjwCjSIfMO72BU+WY=; b=cQn5c5CyaovjjrvvjhFlktdU6gMj0xUaany+JGy5Zvl/VcvumWz4MnSa5odJxaSnOd CAOIQp5t3u/SOmmwTqtWIZMuVWuRuuuRCkEcEtQJ6Lo6UnjUPAG/ADVMNX7NzWaMM+km YRKD6vlIU2SRjDGfgEnfw6NsDhDfxPhKXxM6YE5zB0ZkkeWkX1mD33Oo4U/lMc/T9XD/ 4w8JRiUWwSY1Rr4uzvt05n2ExEsZTxW3Myc9n7NjLz7DJFQMHYY32xgVqxKIsbqLoZ/v PcV7SBBCzTeOcXjVxTotgmUa0pSqXtYwa+NEBCB40ey4iv61E3cppOql6Pd79p4bQapP Fz5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Cx8Lzqfh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m16si13043104pfc.211.2022.01.31.03.48.50; Mon, 31 Jan 2022 03:49:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Cx8Lzqfh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245268AbiA1XSf (ORCPT + 99 others); Fri, 28 Jan 2022 18:18:35 -0500 Received: from mga12.intel.com ([192.55.52.136]:51008 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239722AbiA1XSe (ORCPT ); Fri, 28 Jan 2022 18:18:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643411914; x=1674947914; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=r2T2n+ss+flnTA1SZnYKPHHw9dTVF1ihmv+a8CZs1vw=; b=Cx8LzqfhDjkHGN/d3ZjNsyrYFi9ySlcfAW65k63352ntEqGKfHq+zdCl m9D3oizVHp869fE81L/okMxWqLo0gZu3NVFj/aEyy9+LrFbMz2Vpz198x uyl+FpaYdmAj2WjZUjdL7EkuOFSraJrwovJ8icNE0GWltTapeZ84URG0V 6CcJtuYaRpV4BBqkMPyFNqXsQWpffW5ONPYhsB0mHyJy8MpSkPQYjPS9D jU4jQgAsseM4v6xYtFfcs7bOThQ+Kvn+JM3xb1EA3itcu5ntp90uHG3h1 4GL6NCE7K+/R5wjndir5W3TMH73P98EMKRKZGWk/5kqMSiINByRh6ZkMT w==; X-IronPort-AV: E=McAfee;i="6200,9189,10241"; a="227192036" X-IronPort-AV: E=Sophos;i="5.88,325,1635231600"; d="scan'208";a="227192036" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2022 15:18:33 -0800 X-IronPort-AV: E=Sophos;i="5.88,325,1635231600"; d="scan'208";a="697247335" Received: from zhenkuny-mobl2.amr.corp.intel.com (HELO [10.209.84.59]) ([10.209.84.59]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2022 15:18:33 -0800 Message-ID: Date: Fri, 28 Jan 2022 15:18:29 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.2 Content-Language: en-US To: ira.weiny@intel.com, Dave Hansen , "H. Peter Anvin" , Dan Williams Cc: Fenghua Yu , Rick Edgecombe , linux-kernel@vger.kernel.org References: <20220127175505.851391-1-ira.weiny@intel.com> <20220127175505.851391-10-ira.weiny@intel.com> From: Dave Hansen Subject: Re: [PATCH V8 09/44] x86/pkeys: Enable PKS on cpus which support it In-Reply-To: <20220127175505.851391-10-ira.weiny@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/27/22 09:54, ira.weiny@intel.com wrote: > Protection Keys for Supervisor pages (PKS) enables fast, hardware thread > specific, manipulation of permission restrictions on supervisor page > mappings. It uses the same mechanism of Protection Keys as those on > User mappings but applies that mechanism to supervisor mappings using a > supervisor specific MSR. > > Bit 24 of CR4 is used to enable the feature by software. Define > pks_setup() to be called when PKS is configured. Again, no need to specify the bit numbers. We have it in the code. :) At most, just say something like: PKS is enabled by a new bit in a control register. or PKS is enabled by a new bit in CR4. > Initially, pks_setup() initializes the per-cpu MSR with 0 to enable all > access on all pkeys. Why not just make it restrictive to start out? That's what we do for PKU. > asm/pks.h is added as a new file to store new > internal functions and structures such as pks_setup(). One writing nit: try to speak in active voice. Passive: "Foo is added" Active: "Add foo" It actually makes thing shorter and easier to read: Add asm/pks.h to store new internal functions and structures such as pks_setup(). > diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h > index bcba3c643e63..191c574b2390 100644 > --- a/arch/x86/include/uapi/asm/processor-flags.h > +++ b/arch/x86/include/uapi/asm/processor-flags.h > @@ -130,6 +130,8 @@ > #define X86_CR4_SMAP _BITUL(X86_CR4_SMAP_BIT) > #define X86_CR4_PKE_BIT 22 /* enable Protection Keys support */ > #define X86_CR4_PKE _BITUL(X86_CR4_PKE_BIT) > +#define X86_CR4_PKS_BIT 24 /* enable Protection Keys for Supervisor */ > +#define X86_CR4_PKS _BITUL(X86_CR4_PKS_BIT) > > /* > * x86-64 Task Priority Register, CR8 > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 7b8382c11788..83c1abce7d93 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -59,6 +59,7 @@ > #include > #include > #include > +#include > > #include "cpu.h" > > @@ -1632,6 +1633,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) > > x86_init_rdrand(c); > setup_pku(c); > + pks_setup(); > > /* > * Clear/Set all flags overridden by options, need do it > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c > index cf12d8bf122b..02629219e683 100644 > --- a/arch/x86/mm/pkeys.c > +++ b/arch/x86/mm/pkeys.c > @@ -206,3 +206,19 @@ u32 pkey_update_pkval(u32 pkval, int pkey, u32 accessbits) > pkval &= ~(PKEY_ACCESS_MASK << shift); > return pkval | accessbits << shift; > } > + > +#ifdef CONFIG_ARCH_ENABLE_SUPERVISOR_PKEYS > + > +/* > + * PKS is independent of PKU and either or both may be supported on a CPU. > + */ > +void pks_setup(void) > +{ > + if (!cpu_feature_enabled(X86_FEATURE_PKS)) > + return; > + > + wrmsrl(MSR_IA32_PKRS, 0); This probably needs a one-line comment about what it's doing. As a general rule, I'd much rather have a one-sentence note in a code comment than in the changelog. > + cr4_set_bits(X86_CR4_PKS); > +} > + > +#endif /* CONFIG_ARCH_ENABLE_SUPERVISOR_PKEYS */