From: Dan Williams <dan.j.williams@intel.com> To: tglx@linutronix.de Cc: Mark Rutland <mark.rutland@arm.com>, linux-arch@vger.kernel.org, Kees Cook <keescook@chromium.org>, kernel-hardening@lists.openwall.com, Peter Zijlstra <peterz@infradead.org>, gregkh@linuxfoundation.org, Jonathan Corbet <corbet@lwn.net>, Will Deacon <will.deacon@arm.com>, torvalds@linux-foundation.org, alan@linux.intel.com Subject: [PATCH v5 01/12] Documentation: document array_idx Date: Fri, 26 Jan 2018 23:55:18 -0800 [thread overview] Message-ID: <151703971882.26578.14987326469880344294.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) In-Reply-To: <151703971300.26578.1185595719337719486.stgit@dwillia2-desk3.amr.corp.intel.com> From: Mark Rutland <mark.rutland@arm.com> Document the rationale and usage of the new array_idx() helper. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Peter Zijlstra <peterz@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- Documentation/speculation.txt | 87 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/speculation.txt diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt new file mode 100644 index 000000000000..308177cab617 --- /dev/null +++ b/Documentation/speculation.txt @@ -0,0 +1,87 @@ +This document explains potential effects of speculation, and how undesirable +effects can be mitigated portably using common APIs. + +=========== +Speculation +=========== + +To improve performance and minimize average latencies, many contemporary CPUs +employ speculative execution techniques such as branch prediction, performing +work which may be discarded at a later stage. + +Typically speculative execution cannot be observed from architectural state, +such as the contents of registers. However, in some cases it is possible to +observe its impact on microarchitectural state, such as the presence or +absence of data in caches. Such state may form side-channels which can be +observed to extract secret information. + +For example, in the presence of branch prediction, it is possible for bounds +checks to be ignored by code which is speculatively executed. Consider the +following code: + + int load_array(int *array, unsigned int idx) + { + if (idx >= MAX_ARRAY_ELEMS) + return 0; + else + return array[idx]; + } + +Which, on arm64, may be compiled to an assembly sequence such as: + + CMP <idx>, #MAX_ARRAY_ELEMS + B.LT less + MOV <returnval>, #0 + RET + less: + LDR <returnval>, [<array>, <idx>] + RET + +It is possible that a CPU mis-predicts the conditional branch, and +speculatively loads array[idx], even if idx >= MAX_ARRAY_ELEMS. This value +will subsequently be discarded, but the speculated load may affect +microarchitectural state which can be subsequently measured. + +More complex sequences involving multiple dependent memory accesses may result +in sensitive information being leaked. Consider the following code, building +on the prior example: + + int load_dependent_arrays(int *arr1, int *arr2, int idx) + { + int val1, val2, + + val1 = load_array(arr1, idx); + val2 = load_array(arr2, val1); + + return val2; + } + +Under speculation, the first call to load_array() may return the value of an +out-of-bounds address, while the second call will influence microarchitectural +state dependent on this value. This may provide an arbitrary read primitive. + +==================================== +Mitigating speculation side-channels +==================================== + +The kernel provides a generic API to ensure that bounds checks are respected +even under speculation. Architectures which are affected by speculation-based +side-channels are expected to implement these primitives. + +The array_idx() helper in <linux/nospec.h> can be used to prevent +information from being leaked via side-channels. + +A call to array_idx(idx, sz) returns a sanitized index value that is +bounded to [0, sz) even under cpu speculation conditions. + +This can be used to protect the earlier load_array() example: + + int load_array(int *array, unsigned int idx) + { + if (idx >= MAX_ARRAY_ELEMS) + return 0; + else { + idx = array_idx(idx, MAX_ARRAY_ELEMS); + return array[idx]; + } + }
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com> To: tglx@linutronix.de Cc: Mark Rutland <mark.rutland@arm.com>, linux-arch@vger.kernel.org, Kees Cook <keescook@chromium.org>, kernel-hardening@lists.openwall.com, Peter Zijlstra <peterz@infradead.org>, gregkh@linuxfoundation.org, Jonathan Corbet <corbet@lwn.net>, Will Deacon <will.deacon@arm.com>, torvalds@linux-foundation.org, alan@linux.intel.com Subject: [kernel-hardening] [PATCH v5 01/12] Documentation: document array_idx Date: Fri, 26 Jan 2018 23:55:18 -0800 [thread overview] Message-ID: <151703971882.26578.14987326469880344294.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) In-Reply-To: <151703971300.26578.1185595719337719486.stgit@dwillia2-desk3.amr.corp.intel.com> From: Mark Rutland <mark.rutland@arm.com> Document the rationale and usage of the new array_idx() helper. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Peter Zijlstra <peterz@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- Documentation/speculation.txt | 87 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/speculation.txt diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt new file mode 100644 index 000000000000..308177cab617 --- /dev/null +++ b/Documentation/speculation.txt @@ -0,0 +1,87 @@ +This document explains potential effects of speculation, and how undesirable +effects can be mitigated portably using common APIs. + +=========== +Speculation +=========== + +To improve performance and minimize average latencies, many contemporary CPUs +employ speculative execution techniques such as branch prediction, performing +work which may be discarded at a later stage. + +Typically speculative execution cannot be observed from architectural state, +such as the contents of registers. However, in some cases it is possible to +observe its impact on microarchitectural state, such as the presence or +absence of data in caches. Such state may form side-channels which can be +observed to extract secret information. + +For example, in the presence of branch prediction, it is possible for bounds +checks to be ignored by code which is speculatively executed. Consider the +following code: + + int load_array(int *array, unsigned int idx) + { + if (idx >= MAX_ARRAY_ELEMS) + return 0; + else + return array[idx]; + } + +Which, on arm64, may be compiled to an assembly sequence such as: + + CMP <idx>, #MAX_ARRAY_ELEMS + B.LT less + MOV <returnval>, #0 + RET + less: + LDR <returnval>, [<array>, <idx>] + RET + +It is possible that a CPU mis-predicts the conditional branch, and +speculatively loads array[idx], even if idx >= MAX_ARRAY_ELEMS. This value +will subsequently be discarded, but the speculated load may affect +microarchitectural state which can be subsequently measured. + +More complex sequences involving multiple dependent memory accesses may result +in sensitive information being leaked. Consider the following code, building +on the prior example: + + int load_dependent_arrays(int *arr1, int *arr2, int idx) + { + int val1, val2, + + val1 = load_array(arr1, idx); + val2 = load_array(arr2, val1); + + return val2; + } + +Under speculation, the first call to load_array() may return the value of an +out-of-bounds address, while the second call will influence microarchitectural +state dependent on this value. This may provide an arbitrary read primitive. + +==================================== +Mitigating speculation side-channels +==================================== + +The kernel provides a generic API to ensure that bounds checks are respected +even under speculation. Architectures which are affected by speculation-based +side-channels are expected to implement these primitives. + +The array_idx() helper in <linux/nospec.h> can be used to prevent +information from being leaked via side-channels. + +A call to array_idx(idx, sz) returns a sanitized index value that is +bounded to [0, sz) even under cpu speculation conditions. + +This can be used to protect the earlier load_array() example: + + int load_array(int *array, unsigned int idx) + { + if (idx >= MAX_ARRAY_ELEMS) + return 0; + else { + idx = array_idx(idx, MAX_ARRAY_ELEMS); + return array[idx]; + } + }
next prev parent reply other threads:[~2018-01-27 8:04 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 ` Dan Williams [this message] 2018-01-27 7:55 ` [kernel-hardening] [PATCH v5 01/12] Documentation: document array_idx 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 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=151703971882.26578.14987326469880344294.stgit@dwillia2-desk3.amr.corp.intel.com \ --to=dan.j.williams@intel.com \ --cc=alan@linux.intel.com \ --cc=corbet@lwn.net \ --cc=gregkh@linuxfoundation.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arch@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=will.deacon@arm.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: 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.