From: Ingo Molnar <mingo@kernel.org> To: Dan Williams <dan.j.williams@intel.com> Cc: tglx@linutronix.de, linux-arch@vger.kernel.org, Kees Cook <keescook@chromium.org>, kernel-hardening@lists.openwall.com, gregkh@linuxfoundation.org, x86@kernel.org, Ingo Molnar <mingo@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, torvalds@linux-foundation.org, alan@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 06/12] x86, get_user: use pointer masking to limit speculation Date: Sun, 28 Jan 2018 10:25:28 +0100 [thread overview] Message-ID: <20180128092528.27hufsrytcdzusvk@gmail.com> (raw) In-Reply-To: <151703974570.26578.3809646715924406820.stgit@dwillia2-desk3.amr.corp.intel.com> * Dan Williams <dan.j.williams@intel.com> wrote: > Quoting Linus: > > I do think that it would be a good idea to very expressly document > the fact that it's not that the user access itself is unsafe. I do > agree that things like "get_user()" want to be protected, but not > because of any direct bugs or problems with get_user() and friends, > but simply because get_user() is an excellent source of a pointer > that is obviously controlled from a potentially attacking user > space. So it's a prime candidate for then finding _subsequent_ > accesses that can then be used to perturb the cache. > > Unlike the '__get_user' case 'get_user' includes the address limit check > near the pointer de-reference. With that locality the speculation can be > mitigated with pointer narrowing rather than a barrier. Where the > narrowing is performed by: > > cmp %limit, %ptr > sbb %mask, %mask > and %mask, %ptr > > With respect to speculation the value of %ptr is either less than %limit > or NULL. (The style problems/inconsistencies of the #2 patch are repeated here too.) > --- a/arch/x86/lib/getuser.S > +++ b/arch/x86/lib/getuser.S > @@ -40,6 +40,8 @@ ENTRY(__get_user_1) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 1: movzbl (%_ASM_AX),%edx > xor %eax,%eax > @@ -54,6 +56,8 @@ ENTRY(__get_user_2) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 2: movzwl -1(%_ASM_AX),%edx > xor %eax,%eax > @@ -68,6 +72,8 @@ ENTRY(__get_user_4) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 3: movl -3(%_ASM_AX),%edx > xor %eax,%eax > @@ -83,6 +89,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 4: movq -7(%_ASM_AX),%rdx > xor %eax,%eax > @@ -94,6 +102,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user_8 > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX Please make it clear in the comments that these are essentially open-coded assembly versions of array_idx_mask_nospec(), that the purpose here is to provide as a partial speculation barrier against the value range of user-provided pointers. In a couple of years this sequence will be too obscure to understand at first glance. It would also make it easier to find these spots if someone wants to tweak (or backport) array_idx_mask_nospec() related changes. Thanks, Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org> To: Dan Williams <dan.j.williams@intel.com> Cc: tglx@linutronix.de, linux-arch@vger.kernel.org, Kees Cook <keescook@chromium.org>, kernel-hardening@lists.openwall.com, gregkh@linuxfoundation.org, x86@kernel.org, Ingo Molnar <mingo@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, torvalds@linux-foundation.org, alan@linux.intel.com, linux-kernel@vger.kernel.org Subject: [kernel-hardening] Re: [PATCH v5 06/12] x86, get_user: use pointer masking to limit speculation Date: Sun, 28 Jan 2018 10:25:28 +0100 [thread overview] Message-ID: <20180128092528.27hufsrytcdzusvk@gmail.com> (raw) In-Reply-To: <151703974570.26578.3809646715924406820.stgit@dwillia2-desk3.amr.corp.intel.com> * Dan Williams <dan.j.williams@intel.com> wrote: > Quoting Linus: > > I do think that it would be a good idea to very expressly document > the fact that it's not that the user access itself is unsafe. I do > agree that things like "get_user()" want to be protected, but not > because of any direct bugs or problems with get_user() and friends, > but simply because get_user() is an excellent source of a pointer > that is obviously controlled from a potentially attacking user > space. So it's a prime candidate for then finding _subsequent_ > accesses that can then be used to perturb the cache. > > Unlike the '__get_user' case 'get_user' includes the address limit check > near the pointer de-reference. With that locality the speculation can be > mitigated with pointer narrowing rather than a barrier. Where the > narrowing is performed by: > > cmp %limit, %ptr > sbb %mask, %mask > and %mask, %ptr > > With respect to speculation the value of %ptr is either less than %limit > or NULL. (The style problems/inconsistencies of the #2 patch are repeated here too.) > --- a/arch/x86/lib/getuser.S > +++ b/arch/x86/lib/getuser.S > @@ -40,6 +40,8 @@ ENTRY(__get_user_1) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 1: movzbl (%_ASM_AX),%edx > xor %eax,%eax > @@ -54,6 +56,8 @@ ENTRY(__get_user_2) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 2: movzwl -1(%_ASM_AX),%edx > xor %eax,%eax > @@ -68,6 +72,8 @@ ENTRY(__get_user_4) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 3: movl -3(%_ASM_AX),%edx > xor %eax,%eax > @@ -83,6 +89,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 4: movq -7(%_ASM_AX),%rdx > xor %eax,%eax > @@ -94,6 +102,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user_8 > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX Please make it clear in the comments that these are essentially open-coded assembly versions of array_idx_mask_nospec(), that the purpose here is to provide as a partial speculation barrier against the value range of user-provided pointers. In a couple of years this sequence will be too obscure to understand at first glance. It would also make it easier to find these spots if someone wants to tweak (or backport) array_idx_mask_nospec() related changes. Thanks, Ingo
next prev parent reply other threads:[~2018-01-28 9:25 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-27 7:55 [PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-27 7:55 ` Dan Williams 2018-01-27 7:55 ` [PATCH v5 01/12] Documentation: document array_idx Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-27 7:55 ` [PATCH v5 02/12] array_idx: sanitize speculative array de-references Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 8:55 ` Ingo Molnar 2018-01-28 8:55 ` [kernel-hardening] " Ingo Molnar 2018-01-28 11:36 ` Thomas Gleixner 2018-01-28 11:36 ` [kernel-hardening] " Thomas Gleixner 2018-01-28 16:28 ` Dan Williams 2018-01-28 16:28 ` [kernel-hardening] " Dan Williams 2018-01-28 18:33 ` Ingo Molnar 2018-01-28 18:33 ` [kernel-hardening] " Ingo Molnar 2018-01-29 16:45 ` Dan Williams 2018-01-28 18:36 ` [kernel-hardening] " Thomas Gleixner 2018-01-28 18:36 ` Thomas Gleixner 2018-01-30 6:29 ` Dan Williams 2018-01-30 19:38 ` Linus Torvalds 2018-01-30 20:13 ` Dan Williams 2018-01-30 20:27 ` Van De Ven, Arjan 2018-01-31 8:03 ` Ingo Molnar 2018-01-31 14:13 ` Van De Ven, Arjan 2018-01-31 14:21 ` Greg KH 2018-01-27 7:55 ` [PATCH v5 03/12] x86: implement array_idx_mask Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:02 ` Ingo Molnar 2018-01-28 9:02 ` [kernel-hardening] " Ingo Molnar 2018-01-27 7:55 ` [PATCH v5 04/12] x86: introduce __uaccess_begin_nospec and ifence Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:06 ` Ingo Molnar 2018-01-28 9:06 ` [kernel-hardening] " Ingo Molnar 2018-01-28 9:14 ` Ingo Molnar 2018-01-28 9:14 ` [kernel-hardening] " Ingo Molnar 2018-01-29 20:41 ` Dan Williams 2018-01-30 6:56 ` Ingo Molnar 2018-01-27 7:55 ` [PATCH v5 05/12] x86, __get_user: use __uaccess_begin_nospec Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:19 ` Ingo Molnar 2018-01-28 9:19 ` [kernel-hardening] " Ingo Molnar 2018-01-27 7:55 ` [PATCH v5 06/12] x86, get_user: use pointer masking to limit speculation Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:25 ` Ingo Molnar [this message] 2018-01-28 9:25 ` [kernel-hardening] " Ingo Molnar 2018-01-27 7:55 ` [PATCH v5 07/12] x86: remove the syscall_64 fast-path Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:29 ` Ingo Molnar 2018-01-28 9:29 ` [kernel-hardening] " Ingo Molnar 2018-01-28 15:22 ` Andy Lutomirski 2018-01-28 15:22 ` [kernel-hardening] " Andy Lutomirski 2018-01-27 7:55 ` [PATCH v5 08/12] x86: sanitize sycall table de-references under speculation Dan Williams 2018-01-27 7:55 ` [kernel-hardening] " Dan Williams 2018-01-28 9:36 ` Ingo Molnar 2018-01-28 9:36 ` [kernel-hardening] " Ingo Molnar 2018-01-27 7:56 ` [PATCH v5 09/12] vfs, fdtable: prevent bounds-check bypass via speculative execution Dan Williams 2018-01-27 7:56 ` [kernel-hardening] " Dan Williams 2018-01-27 7:56 ` [PATCH v5 10/12] kvm, x86: update spectre-v1 mitigation Dan Williams 2018-01-27 7:56 ` [kernel-hardening] " Dan Williams 2018-01-27 7:56 ` [PATCH v5 11/12] nl80211: sanitize array index in parse_txq_params Dan Williams 2018-01-27 7:56 ` [kernel-hardening] " Dan Williams 2018-01-27 7:56 ` Dan Williams 2018-01-27 7:56 ` [PATCH v5 12/12] x86/spectre: report get_user mitigation for spectre_v1 Dan Williams 2018-01-27 7:56 ` [kernel-hardening] " Dan Williams 2018-01-28 9:50 ` Ingo Molnar 2018-01-28 9:50 ` [kernel-hardening] " Ingo Molnar 2018-01-29 22:05 ` Dan Williams 2018-01-31 8:07 ` Ingo Molnar 2018-02-01 20:23 ` Dan Williams 2018-01-27 18:52 ` [PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti Linus Torvalds 2018-01-27 18:52 ` [kernel-hardening] " Linus Torvalds 2018-01-27 18:52 ` Linus Torvalds 2018-01-27 19:26 ` Dan Williams 2018-01-27 19:26 ` [kernel-hardening] " Dan Williams 2018-01-27 19:26 ` Dan Williams
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=20180128092528.27hufsrytcdzusvk@gmail.com \ --to=mingo@kernel.org \ --cc=alan@linux.intel.com \ --cc=dan.j.williams@intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=x86@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.