From: Kees Cook <keescook@chromium.org>
To: ira.weiny@intel.com
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Dan Williams <dan.j.williams@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH V10 14/44] mm/pkeys: Introduce pks_set_readwrite()
Date: Mon, 9 May 2022 14:38:38 -0700 [thread overview]
Message-ID: <202205091304.434A9B45@keescook> (raw)
In-Reply-To: <20220419170649.1022246-15-ira.weiny@intel.com>
On Tue, Apr 19, 2022 at 10:06:19AM -0700, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> When kernel code needs access to a PKS protected page they will need to
> change the protections for the pkey to Read/Write.
I'm excited to have this infrastructure available! It'll finally give us
the "write rarely" infrastructure we've needed:
https://github.com/KSPP/linux/issues/130
>
> Define pks_set_readwrite() to update the specified pkey. Define
> pks_update_protection() as a helper to do the heavy lifting and allow
> for subsequent pks_set_*() calls.
>
> Define PKEY_READ_WRITE rather than use a magic value of '0' in
> pks_update_protection().
>
> Finally, ensure preemption is disabled for pks_write_pkrs() because the
> context of this call can not generally be predicted.
>
> pks.h is created to avoid conflicts and header dependencies with the
> user space pkey code.
>
> Add documentation.
>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> changes for v9
> Move MSR documentation note to this patch
> move declarations to incline/linux/pks.h
> from rick edgecombe
> change pkey type to u8
> validate pkey range in pks_update_protection
> from 0day
> fix documentation link
> from dave hansen
> s/pks_mk_*/pks_set_*/
> use pkey
> s/pks_saved_pkrs/pkrs/
>
> changes for v8
> define pkey_read_write
> make the call inline
> clean up the names
> use pks_write_pkrs() with preemption disabled
> split this out from 'add pks kernel api'
> include documentation in this patch
> ---
> Documentation/core-api/protection-keys.rst | 15 +++++++++++
> arch/x86/mm/pkeys.c | 31 ++++++++++++++++++++++
> include/linux/pks.h | 31 ++++++++++++++++++++++
> include/uapi/asm-generic/mman-common.h | 1 +
> 4 files changed, 78 insertions(+)
> create mode 100644 include/linux/pks.h
>
> diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst
> index fe63acf5abbe..3af92e1cbffd 100644
> --- a/Documentation/core-api/protection-keys.rst
> +++ b/Documentation/core-api/protection-keys.rst
> @@ -142,3 +142,18 @@ Adding pages to a pkey protected domain
>
> .. kernel-doc:: arch/x86/include/asm/pgtable_types.h
> :doc: PKS_KEY_ASSIGNMENT
> +
> +Changing permissions of individual keys
> +---------------------------------------
> +
> +.. kernel-doc:: include/linux/pks.h
> + :identifiers: pks_set_readwrite
> +
> +MSR details
> +~~~~~~~~~~~
> +
> +WRMSR is typically an architecturally serializing instruction. However,
> +WRMSR(MSR_IA32_PKRS) is an exception. It is not a serializing instruction and
> +instead maintains ordering properties similar to WRPKRU. Thus it is safe to
> +immediately use a mapping when the pks_set*() functions returns. Check the
> +latest SDM for details.
> diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> index 39e4c2cbc279..e4cbc79686ea 100644
> --- a/arch/x86/mm/pkeys.c
> +++ b/arch/x86/mm/pkeys.c
> @@ -6,6 +6,7 @@
> #include <linux/debugfs.h> /* debugfs_create_u32() */
> #include <linux/mm_types.h> /* mm_struct, vma, etc... */
> #include <linux/pkeys.h> /* PKEY_* */
> +#include <linux/pks.h>
> #include <linux/pks-keys.h>
> #include <uapi/asm-generic/mman-common.h>
>
> @@ -275,4 +276,34 @@ void pks_setup(void)
> cr4_set_bits(X86_CR4_PKS);
> }
>
> +/*
> + * Do not call this directly, see pks_set*().
> + *
> + * @pkey: Key for the domain to change
> + * @protection: protection bits to be used
> + *
> + * Protection utilizes the same protection bits specified for User pkeys
> + * PKEY_DISABLE_ACCESS
> + * PKEY_DISABLE_WRITE
> + *
> + */
> +void pks_update_protection(u8 pkey, u8 protection)
For better security, I think this should be a static inline, not a
callable (i.e. as a non-inline it could be the target of a control
flow attack).
> +{
> + u32 pkrs;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_PKS))
> + return;
> +
> + if (WARN_ON_ONCE(pkey >= PKS_KEY_MAX))
> + return;
I think this should enforce arguments being __builtin_constant_p(). i.e.
making sure that all callers of pks_update_protection() are using a
compile-time constant value. That makes it so that the caller location
and key become hard-coded (i.e. further reduction in risk to becoming a
control-flow gadget: the inlining of a const value means no arguments
any more). For example:
BUILD_BUG_ON(!__builtin_constant_p(pkey));
BUILD_BUG_ON(!__builtin_constant_p(protection));
(I think the test code will need some tweaking, but it should be
possible to adjust it.)
> +
> + pkrs = current->thread.pkrs;
> + current->thread.pkrs = pkey_update_pkval(pkrs, pkey,
> + protection);
> + preempt_disable();
> + pks_write_pkrs(current->thread.pkrs);
> + preempt_enable();
To resist cross-thread attacks, please:
- make pkey_update_pkval() also an inline
- use the pkrs variable directly and store it back only after the write
For example:
preempt_disable();
pkrs = pkey_update_pkval(current->thread.pkrs,
pkey, protection);
pks_write_pkrs(pkrs);
current->thread.pkrs = pkrs;
preempt_enable();
This means that the pkey/protection relationship always lives in a
CPU-local register and cannot be manipulated by another CPU before the
msr write completes. Better yet would be:
preempt_disable();
rdmsrl(MSR_IA32_PKRS, pkrs);
pkrs = pkey_update_pkval(pkrs, pkey, protection);
pks_write_pkrs(pkrs);
current->thread.pkrs = pkrs;
preempt_enable();
Then cross-thread attacks cannot corrupt the _other_ PKS keys (i.e.
write the desired changes to target's current->thread.kprs and trigger
an update to a different pkey, resulting in flushing the attacker's
changes to that CPU's pkey state.
> +/**
> + * pks_set_readwrite() - Make the domain Read/Write
> + * @pkey: the pkey for which the access should change.
> + *
> + * Allow all access, read and write, to the domain specified by pkey. This is
> + * not a global update and only affects the current running thread.
> + */
> +static inline void pks_set_readwrite(u8 pkey)
> +{
> + pks_update_protection(pkey, PKEY_READ_WRITE);
> +}
While adding these, can you please also add pks_set_nowrite()? This
will be needed for protecting writes to memory that should be otherwise
readable.
With these changes it should be possible to protect the kernel's page
table entries from "stray" writes. :)
-Kees
> +
> +#else /* !CONFIG_ARCH_ENABLE_SUPERVISOR_PKEYS */
> +
> +static inline void pks_set_readwrite(u8 pkey) {}
> +
> +#endif /* CONFIG_ARCH_ENABLE_SUPERVISOR_PKEYS */
> +
> +#endif /* _LINUX_PKS_H */
> diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
> index 6c1aa92a92e4..f179544bd33a 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -80,6 +80,7 @@
> /* compatibility flags */
> #define MAP_FILE 0
>
> +#define PKEY_READ_WRITE 0x0
> #define PKEY_DISABLE_ACCESS 0x1
> #define PKEY_DISABLE_WRITE 0x2
> #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> --
> 2.35.1
>
--
Kees Cook
next prev parent reply other threads:[~2022-05-09 21:38 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 17:06 [PATCH V10 00/44] PKS/PMEM: Add Stray Write Protection ira.weiny
2022-04-19 17:06 ` [PATCH V10 01/44] Documentation/protection-keys: Clean up documentation for User Space pkeys ira.weiny
2022-06-07 23:09 ` [tip: x86/mm] " tip-bot2 for Ira Weiny
2022-04-19 17:06 ` [PATCH V10 02/44] x86/pkeys: Clarify PKRU_AD_KEY macro ira.weiny
2022-06-07 23:09 ` [tip: x86/mm] " tip-bot2 for Ira Weiny
2022-04-19 17:06 ` [PATCH V10 03/44] x86/pkeys: Make PKRU macros generic ira.weiny
2022-04-19 17:06 ` [PATCH V10 04/44] x86/fpu: Refactor arch_set_user_pkey_access() ira.weiny
2022-04-19 17:06 ` [PATCH V10 05/44] mm/pkeys: Add Kconfig options for PKS ira.weiny
2022-04-19 17:06 ` [PATCH V10 06/44] x86/pkeys: Add PKS CPU feature bit ira.weiny
2022-04-19 17:06 ` [PATCH V10 07/44] x86/fault: Adjust WARN_ON for pkey fault ira.weiny
2022-04-19 17:06 ` [PATCH V10 08/44] Documentation/pkeys: Add initial PKS documentation ira.weiny
2022-05-09 22:03 ` Kees Cook
2022-05-10 17:18 ` Ira Weiny
2022-05-10 20:17 ` Kees Cook
2022-04-19 17:06 ` [PATCH V10 09/44] mm/pkeys: Provide for PKS key allocation ira.weiny
2022-04-19 17:06 ` [PATCH V10 10/44] x86/pkeys: Enable PKS on cpus which support it ira.weiny
2022-04-19 17:06 ` [PATCH V10 11/44] mm/pkeys: Define PKS page table macros ira.weiny
2022-04-19 17:06 ` [PATCH V10 12/44] x86/pkeys: Introduce pks_write_pkrs() ira.weiny
2022-04-19 17:06 ` [PATCH V10 13/44] x86/pkeys: Preserve the PKS MSR on context switch ira.weiny
2022-04-19 17:06 ` [PATCH V10 14/44] mm/pkeys: Introduce pks_set_readwrite() ira.weiny
2022-05-09 21:38 ` Kees Cook [this message]
2022-05-10 21:33 ` Ira Weiny
2022-05-10 22:08 ` Kees Cook
2022-05-10 22:26 ` Edgecombe, Rick P
2022-05-11 3:15 ` Kees Cook
2022-05-11 17:59 ` Ira Weiny
2022-04-19 17:06 ` [PATCH V10 15/44] mm/pkeys: Introduce pks_set_noaccess() ira.weiny
2022-04-19 17:06 ` [PATCH V10 16/44] mm/pkeys: Introduce PKS fault callbacks ira.weiny
2022-04-19 17:06 ` [PATCH V10 17/44] x86/entry: Add auxiliary pt_regs space ira.weiny
2022-04-19 17:06 ` [PATCH V10 18/44] entry: Pass pt_regs to irqentry_exit_cond_resched() ira.weiny
2022-04-19 17:06 ` [PATCH V10 19/44] entry: Add calls for save/restore auxiliary pt_regs ira.weiny
2022-04-19 17:06 ` [PATCH V10 20/44] x86/entry: Define arch_{save|restore}_auxiliary_pt_regs() ira.weiny
2022-04-19 17:06 ` [PATCH V10 21/44] x86/pkeys: Preserve PKRS MSR across exceptions ira.weiny
2022-04-19 17:06 ` [PATCH V10 22/44] x86/fault: Print PKS MSR on fault ira.weiny
2022-04-19 17:06 ` [PATCH V10 23/44] mm/pkeys: Introduce pks_update_exception() ira.weiny
2022-04-19 17:06 ` [PATCH V10 24/44] mm/pkeys: Add pks_available() ira.weiny
2022-04-19 17:06 ` [PATCH V10 25/44] memremap_pages: Add Kconfig for DEVMAP_ACCESS_PROTECTION ira.weiny
2022-04-19 17:06 ` [PATCH V10 26/44] memremap_pages: Introduce pgmap_protection_available() ira.weiny
2022-04-19 17:06 ` [PATCH V10 27/44] memremap_pages: Introduce a PGMAP_PROTECTION flag ira.weiny
2022-04-19 17:06 ` [PATCH V10 28/44] memremap_pages: Introduce devmap_protected() ira.weiny
2022-04-19 17:06 ` [PATCH V10 29/44] memremap_pages: Reserve a PKS pkey for eventual use by PMEM ira.weiny
2022-04-19 17:06 ` [PATCH V10 30/44] memremap_pages: Set PKS pkey in PTEs if requested ira.weiny
2022-04-19 17:06 ` [PATCH V10 31/44] memremap_pages: Define pgmap_set_{readwrite|noaccess}() calls ira.weiny
2022-04-19 17:06 ` [PATCH V10 32/44] memremap_pages: Add memremap.pks_fault_mode ira.weiny
2022-04-19 17:06 ` [PATCH V10 33/44] kmap: Make kmap work for devmap protected pages ira.weiny
2022-04-28 15:50 ` Christoph Hellwig
2022-05-12 1:25 ` Ira Weiny
2022-05-17 22:46 ` Ira Weiny
2022-05-18 7:33 ` Christoph Hellwig
2022-05-19 20:29 ` Ira Weiny
2022-04-19 17:06 ` [PATCH V10 34/44] dax: Stray access protection for dax_direct_access() ira.weiny
2022-04-19 17:06 ` [PATCH V10 35/44] nvdimm/pmem: Enable stray access protection ira.weiny
2022-04-19 17:06 ` [PATCH V10 36/44] devdax: " ira.weiny
2022-04-19 17:06 ` [PATCH V10 37/44] mm/pkeys: PKS testing, add initial test code ira.weiny
2022-04-19 17:06 ` [PATCH V10 38/44] x86/selftests: Add test_pks ira.weiny
2022-04-19 17:06 ` [PATCH V10 39/44] mm/pkeys: PKS testing, add a fault call back ira.weiny
2022-04-19 17:06 ` [PATCH V10 40/44] mm/pkeys: PKS testing, add pks_set_*() tests ira.weiny
2022-04-19 17:06 ` [PATCH V10 41/44] mm/pkeys: PKS testing, test context switching ira.weiny
2022-04-19 17:06 ` [PATCH V10 42/44] mm/pkeys: PKS testing, Add exception test ira.weiny
2022-04-19 17:06 ` [PATCH V10 43/44] mm/pkeys: PKS testing, test pks_update_exception() ira.weiny
2022-04-19 17:06 ` [PATCH V10 44/44] mm/pkeys: PKS testing, add test for all keys ira.weiny
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=202205091304.434A9B45@keescook \
--to=keescook@chromium.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=rick.p.edgecombe@intel.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox