Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 2/12/19 4:00 AM, Thomas Gleixner wrote: > Tim, > > On Wed, 30 Jan 2019, Thomas Gleixner wrote: >> Also please follow the L1TF documentation which explains for each of the >> mitigation modes which kind of attacks are prevented and which holes >> remain. >> >> It's a good start but far from where it should be. > > what's the state of this? I was pulled to work on some other tasks. Will come back to updating the document later in the week. Sorry for the delay. Thanks. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
Tim, On Wed, 30 Jan 2019, Thomas Gleixner wrote: > Also please follow the L1TF documentation which explains for each of the > mitigation modes which kind of attacks are prevented and which holes > remain. > > It's a good start but far from where it should be. what's the state of this? Thanks, tglx
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
Tim,
On Fri, 21 Dec 2018, Tim Chen wrote:
> Andi and I have made an update to our draft of the Spectre admin guide.
> We may be out on Christmas vacation for a while. But we want to
> send it out for everyone to take a look.
Yup, it fell through my Christmas cracks as well.
> ---
> Documentation/admin-guide/spectre.rst | 502
> ++
I agree with Jonathan that this wants to be placed differently. Sorry, I
set the precedence with the l1tf document, but I didn't come up with a good
place either.
Something like admin-guide/hardware-vulnerabilities/... might work.
> +The following CPUs are vulnerable:
> +
> +- Intel Core, Atom, Pentium, Xeon CPUs
> +- AMD CPUs like Phenom, EPYC, Zen.
> +- IBM processors like POWER and zSeries
> +- Higher end ARM processors
> +- Apple CPUs
> +- Higher end MIPS CPUs
> +- Likely most other high performance CPUs. Contact your CPU vendor for
> details.
> +
> +This document describes the mitigations on Intel CPUs. Mitigations
> +on other architectures may be different.
No. A lot of the information is the same for all other CPU vendors. So
sharing that document makes a lot of sense. Intel is not the center of the
universe.
> +Problem
> +---
> +
> +CPUs have shared caches, such as buffers for branch prediction, which are
> +later used to guide speculative execution. These buffers are not flushed
> +over context switches or change in privilege levels. Malicious software
change of privilege levels
> +might influence these buffers and trigger specific speculative execution
> +in the kernel or different user processes. This speculative execution can
> +then be used to read data in memory and cause side effects, such as
> displacing
> +data in a data cache. The side effect can then later be measured by the
> +malicious software, and used to determine the memory values read
> speculatively.
> +
> +Spectre attacks allow tricking other software to disclose
> +values in their memory.
No. Spectre attacks do not allow that. It's the hardware properties which
allow attackers to exploit the side effects of speculative execution.
> +In a typical Spectre variant 1 attack, the attacker passes an parameter
Please explain first what the fundamental difference between variant 1 and
variant 2 is. Then go into details of each variant.
> +to a victim. The victim boundary checks the parameter and rejects illegal
> +values. However due to speculation over branch prediction the code path
> +for correct values might be speculatively executed, then reference memory
reference memory?
> +controlled by the input parameter and leave measurable side effects in
> +the caches.
This really is not describing it properly. Please spell out the most
obvious (at least for this who know) attack vector, i.e. array access based
on the input parameter. That's where the bound check is bypassed.
The attacker could then measure these side effects
> +and determine the leaked value.
> +
> +There are some extensions of Spectre variant 1 attacks for reading
> +data over the network, see [2]. However the attacks are very
> +difficult, low bandwidth and fragile and considered low risk.
> +
> +For Spectre variant 2 the attacker poisons the indirect branch
> +predictors of the CPU.
At least some high level explanation how that poisoning happens would be
appropriate.
> ... Then control is passed to the victim, which
> +executes indirect branches. Due to the poisoned branch predictor data
> +the CPU can speculatively execute arbitrary code in the victim's
> +address space, such as a code sequence ("disclosure gadget") that
> +reads arbitrary data on some input parameter and causes a measurable
> +cache side effect based on the value. The attacker can then measure
> +this side effect after gaining control again and determine the value.
> +
> +The most useful gadgets take an attacker-controlled input parameter so
> +that the memory read can be controlled. Gadgets without input parameters
> +might be possible, but the attacker would have very little control over what
> +memory can be read, reducing the risk of the attack revealing useful data.
Makes sense.
> +Attack scenarios
> +
> +
> +Here is a list of attack scenarios that have been anticipated, but
> +may not cover all possible attack patterns. Reduing the occurrences of
> +attack pre-requisites listed can reduce the risk that a spectre attack
> +leaks useful data.
> +
> +1. Local User process attacking kernel
> +^^
> +
> +Code in system calls often enforces access controls with conditional
> +branches based on user data. These branches are potential targets for
> +Spectre v2 exploits. Interrupt handlers, on the other hand, rarely
> +handle user data or enforce access controls, which makes them unlikely
> +exploit targets.
> +
> +For typical variant 2 attack, the attacker may poison the CPU branch
> +buffers first, and then enter the kernel and
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 1/14/2019 5:06 AM, Jiri Kosina wrote: On Mon, 14 Jan 2019, Pavel Machek wrote: Frankly I'd not call it Meltdown, as it works only on data in the cache, so the defense is completely different. Seems more like a l1tf :-). Meltdown on x86 also seems to work only for data in L1D, but the pipeline could be constructed in a way that data are actually fetched into L1D before speculation gives up, which is not the case on ppc (speculation aborts on L2->L1 propagation IIRC). That's why flushing L1D on ppc is sufficient, but on x86 it's not. assuming L1D is not shared between SMT threads obviously :)
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Mon, 14 Jan 2019, Pavel Machek wrote: > Frankly I'd not call it Meltdown, as it works only on data in the cache, > so the defense is completely different. Seems more like a l1tf > :-). Meltdown on x86 also seems to work only for data in L1D, but the pipeline could be constructed in a way that data are actually fetched into L1D before speculation gives up, which is not the case on ppc (speculation aborts on L2->L1 propagation IIRC). That's why flushing L1D on ppc is sufficient, but on x86 it's not. -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Mon 2019-01-14 13:06:24, Jiri Kosina wrote: > On Mon, 14 Jan 2019, Pavel Machek wrote: > > > > > That one really is Intel-specific (not even all x86s are affectd). Same > > > > for Meltdown. > > > > > > At least for Meltdown, your claim is simply not correct. > > > > You are right, there may be few ARM chips affected by meltdown. > > And some of the powerpc64s as well. Do you mean this? https://lkml.org/lkml/2018/1/8/649 Frankly I'd not call it Meltdown, as it works only on data in the cache, so the defense is completely different. Seems more like a l1tf :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Mon, 14 Jan 2019, Pavel Machek wrote: > > > That one really is Intel-specific (not even all x86s are affectd). Same > > > for Meltdown. > > > > At least for Meltdown, your claim is simply not correct. > > You are right, there may be few ARM chips affected by meltdown. And some of the powerpc64s as well. -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Mon 2019-01-14 00:12:59, Jiri Kosina wrote: > On Mon, 14 Jan 2019, Pavel Machek wrote: > > > That one really is Intel-specific (not even all x86s are affectd). Same > > for Meltdown. > > At least for Meltdown, your claim is simply not correct. You are right, there may be few ARM chips affected by meltdown. I don't know about any non-Intel affected by l1tf. ...and its documentation is just plain wrong, explaining I'm protected when I'm not... commit f372cd79be31382ae6030a1f15638cc7fe9eeb9f Author: Pavel Date: Thu Jan 3 00:48:40 2019 +0100 Ok, I guess L1TF was a lot of fun, and there was not time for a good documentation. There's admin guide that is written as an advertisment, and unfortunately is slightly "inaccurate" at places (to the point of lying). Plus, I believe it should go to x86/ directory, as this is really Intel issue, and not anything ARM (or RISC-V) people need to know. Signed-off-by: Pavel Machek diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst index 9af9773..05c5422 100644 --- a/Documentation/admin-guide/l1tf.rst +++ b/Documentation/admin-guide/l1tf.rst @@ -1,10 +1,11 @@ L1TF - L1 Terminal Fault -L1 Terminal Fault is a hardware vulnerability which allows unprivileged -speculative access to data which is available in the Level 1 Data Cache -when the page table entry controlling the virtual address, which is used -for the access, has the Present bit cleared or other reserved bits set. +L1 Terminal Fault is a hardware vulnerability on most recent Intel x86 +CPUs which allows unprivileged speculative access to data which is +available in the Level 1 Data Cache when the page table entry +controlling the virtual address, which is used for the access, has the +Present bit cleared or other reserved bits set. Affected processors --- @@ -76,12 +77,14 @@ Attack scenarios deterministic and more practical. The Linux kernel contains a mitigation for this attack vector, PTE - inversion, which is permanently enabled and has no performance - impact. The kernel ensures that the address bits of PTEs, which are not - marked present, never point to cacheable physical memory space. - - A system with an up to date kernel is protected against attacks from - malicious user space applications. + inversion, which is permanently enabled and has no measurable + performance impact in most configurations. The kernel ensures that + the address bits of PTEs, which are not marked present, never point + to cacheable physical memory space. On x86-32, this physical memory + needs to be limited to 2GiB to make mitigation effective. + + Mitigation is present in kernels v4.19 and newer, and in + recent -stable kernels. 2. Malicious guest in a virtual machine ^^^ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Mon, 14 Jan 2019, Pavel Machek wrote: > That one really is Intel-specific (not even all x86s are affectd). Same > for Meltdown. At least for Meltdown, your claim is simply not correct. -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
Hi! > >> > >> Signed-off-by: Andi Kleen > >> Signed-off-by: Tim Chen > >> --- > >> Documentation/admin-guide/spectre.rst | 502 > >> ++ > >> 1 file changed, 502 insertions(+) > >> create mode 100644 Documentation/admin-guide/spectre.rst > > > > I only saw this now, seems I wasn't copied... I'll take a deeper look, but > > Thanks for taking a look. I'll make sure you are copied on the updates. > > > I have a couple of meta comments: > > > > - This could arguably go in the security book rather than the admin > >guide. I don't really have a strong opinion on which is right at the > >moment, but others might. > > Since l1tf.rst is already here in admin guide, that's why I keep spectre.rst > here as well. I believe l1tf is misplaced. That one really is Intel-specific (not even all x86s are affectd). Same for Meltdown. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Tue, Jan 08, 2019 at 05:41:37PM -0800, Tim Chen wrote: > On 1/8/19 5:11 PM, Alexei Starovoitov wrote: > > >> > >> Alexi, > >> > >> Do you have any suggestions on how to rewrite this two paragraphs? You > >> are probably the best person to update content for this section. > > > > how about moving bpf bits out of this doc and placing them under > > Documentation/bpf/ ? > > We can create bpf_security.rst there with specdown mitigations, best > > practices, > > useful sysctl and config knobs, etc. > > > > Maybe we can provide some minimum but accurate info here on this category of > Spectre attack > for completeness. We can later provide a link to bpf_security.rst here with > more details > when that becomes available. > > Otherwise, I can remove it if you prefer. But people concerned about Spectre > will most likely read > this doc first. I want them to be pointed to the detailed BPF security doc. since Documentation/ got converted to .rst, the links made it easy to follow from one doc into another. I think splitting big doc makes it easier for users to read and for us to maintain/update.
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 1/8/19 5:11 PM, Alexei Starovoitov wrote: >> >> Alexi, >> >> Do you have any suggestions on how to rewrite this two paragraphs? You >> are probably the best person to update content for this section. > > how about moving bpf bits out of this doc and placing them under > Documentation/bpf/ ? > We can create bpf_security.rst there with specdown mitigations, best > practices, > useful sysctl and config knobs, etc. > Maybe we can provide some minimum but accurate info here on this category of Spectre attack for completeness. We can later provide a link to bpf_security.rst here with more details when that becomes available. Otherwise, I can remove it if you prefer. But people concerned about Spectre will most likely read this doc first. I want them to be pointed to the detailed BPF security doc. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 1/8/19 4:58 PM, Ben Greear wrote: > On 1/7/19 9:57 AM, Tim Chen wrote: >> On 12/31/18 8:22 AM, Ben Greear wrote: >>> >>> >>> On 12/21/2018 05:17 PM, Tim Chen wrote: If you don't worry about security and performance is paramount, then boot with "nospectre_v2". That's explained in the document. >>> >>> There seem to be lots of different variants of this type of problem. It >>> was not clear >>> to me that just doing nospectre_v2 would be sufficient to get back full >>> performance. >> >> The performance penalty comes from retpoline penalizing indirect branch >> predictions in kernel. >> With nospectre_v2, retpoline is disabled so you should get all the >> performance >> back from spectre mitigation. >> >> This does not disable kernel page table isolation for meltdown mitigation, >> which also >> needs to be turned off if you want to get the full performance back. That's >> somewhat >> beyond the scope of this doc on Spectre. > > The two bug families (spectre and meltdown) are conflated in my mind, at > least. > > For those of us who do not really understand this stuff in detail, it would > be good to at least mention some notes about Meltdown I think. Probably Meltdown deserves its own meltdown.rst, I think. > >>> And anyway, I would like to compile the kernel to not need that >>> command-line option, >>> so I am still interesting in what compile options need to be set to what >>> values... >>> >> >> If you just want to disable spectre mitigation, setting CONFIG_RETPOLINE=n >> should do >> the trick. If you also want to disable meltdown mitigation, >> set CONFIG_PAGE_TABLE_ISOLATION=n. > > Ok, are there any other CONFIG options that relate to fixing security bugs > that > have noticeable performance impacts or are these two the complete list? > There are those related to Speculative Store Bypass Disable (SSBD) and L1 Terminal Fault (L1TF). SSBD affects mostly sandboxed code so you should not have performance impact unless you are running code sandboxed with SECCOMP. L1TF has its own explanation in l1tf.rst and affects performance mostly of VM. So you should be good if you turn off retpoline and page table isolation in your config if those things don't affect you. If we want a single CONFIG to turn all these off, like what Arjan suggested, that will be a separate topic and discussions. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Tue, Jan 08, 2019 at 01:12:45PM -0800, Tim Chen wrote: > On 12/23/18 3:11 PM, Alexei Starovoitov wrote: > > On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote: > >> + > >> +4. Kernel sandbox attacking kernel > >> +^^ > >> + > >> +The kernel has support for running user-supplied programs within the > >> +kernel. Specific rules (such as bounds checking) are enforced on these > >> +programs by the kernel to ensure that they do not violate access controls. > >> + > >> +eBPF is a kernel sub-system that uses user-supplied program > >> +to execute JITed untrusted byte code inside the kernel. eBPF is used > >> +for manipulating and examining network packets, examining system call > >> +parameters for sand boxes and other uses. > >> + > >> +A malicious local process could upload and trigger an malicious > >> +eBPF script to the kernel, with the script attacking the kernel > >> +using variant 1 or 2 and reading memory. > > > > Above is not correct. > > The exploit for var2 does not load bpf progs into kernel. > > Instead the bpf interpreter is speculatively executing bpf prog > > that was never loaded. > > Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder > > to exploit. > > Same goes for other in kernel interpreters and state machines. > > > >> + > >> +Necessary Prerequisites: > >> +1. Malicious local process > >> +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets > >> +on the same machine. > > > > This is not quite correct either. > > Var 1 could have been exploited with and without JIT. > > Also above sounds like that var1 is still exploitable through bpf > > which is not the case. > > > > Alexi, > > Do you have any suggestions on how to rewrite this two paragraphs? You > are probably the best person to update content for this section. how about moving bpf bits out of this doc and placing them under Documentation/bpf/ ? We can create bpf_security.rst there with specdown mitigations, best practices, useful sysctl and config knobs, etc.
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 1/7/19 9:57 AM, Tim Chen wrote: On 12/31/18 8:22 AM, Ben Greear wrote: On 12/21/2018 05:17 PM, Tim Chen wrote: If you don't worry about security and performance is paramount, then boot with "nospectre_v2". That's explained in the document. There seem to be lots of different variants of this type of problem. It was not clear to me that just doing nospectre_v2 would be sufficient to get back full performance. The performance penalty comes from retpoline penalizing indirect branch predictions in kernel. With nospectre_v2, retpoline is disabled so you should get all the performance back from spectre mitigation. This does not disable kernel page table isolation for meltdown mitigation, which also needs to be turned off if you want to get the full performance back. That's somewhat beyond the scope of this doc on Spectre. The two bug families (spectre and meltdown) are conflated in my mind, at least. For those of us who do not really understand this stuff in detail, it would be good to at least mention some notes about Meltdown I think. And anyway, I would like to compile the kernel to not need that command-line option, so I am still interesting in what compile options need to be set to what values... If you just want to disable spectre mitigation, setting CONFIG_RETPOLINE=n should do the trick. If you also want to disable meltdown mitigation, set CONFIG_PAGE_TABLE_ISOLATION=n. Ok, are there any other CONFIG options that relate to fixing security bugs that have noticeable performance impacts or are these two the complete list? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/28/18 9:34 AM, Jonathan Corbet wrote: >> >> Signed-off-by: Andi Kleen >> Signed-off-by: Tim Chen >> --- >> Documentation/admin-guide/spectre.rst | 502 >> ++ >> 1 file changed, 502 insertions(+) >> create mode 100644 Documentation/admin-guide/spectre.rst > > I only saw this now, seems I wasn't copied... I'll take a deeper look, but Thanks for taking a look. I'll make sure you are copied on the updates. > I have a couple of meta comments: > > - This could arguably go in the security book rather than the admin >guide. I don't really have a strong opinion on which is right at the >moment, but others might. Since l1tf.rst is already here in admin guide, that's why I keep spectre.rst here as well. > > - Wherever it ends up, can you also please add it to the appropriate >index.rst file so it actually gets built with the rest of the docs? Yes, index.rst needs update too. Thanks. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/23/18 3:11 PM, Alexei Starovoitov wrote: > On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote: >> + >> +4. Kernel sandbox attacking kernel >> +^^ >> + >> +The kernel has support for running user-supplied programs within the >> +kernel. Specific rules (such as bounds checking) are enforced on these >> +programs by the kernel to ensure that they do not violate access controls. >> + >> +eBPF is a kernel sub-system that uses user-supplied program >> +to execute JITed untrusted byte code inside the kernel. eBPF is used >> +for manipulating and examining network packets, examining system call >> +parameters for sand boxes and other uses. >> + >> +A malicious local process could upload and trigger an malicious >> +eBPF script to the kernel, with the script attacking the kernel >> +using variant 1 or 2 and reading memory. > > Above is not correct. > The exploit for var2 does not load bpf progs into kernel. > Instead the bpf interpreter is speculatively executing bpf prog > that was never loaded. > Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder > to exploit. > Same goes for other in kernel interpreters and state machines. > >> + >> +Necessary Prerequisites: >> +1. Malicious local process >> +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets >> +on the same machine. > > This is not quite correct either. > Var 1 could have been exploited with and without JIT. > Also above sounds like that var1 is still exploitable through bpf > which is not the case. > Alexi, Do you have any suggestions on how to rewrite this two paragraphs? You are probably the best person to update content for this section. Thanks. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/31/18 8:22 AM, Ben Greear wrote: > > > On 12/21/2018 05:17 PM, Tim Chen wrote: >> >> If you don't worry about security and performance is paramount, then >> boot with "nospectre_v2". That's explained in the document. > > There seem to be lots of different variants of this type of problem. It was > not clear > to me that just doing nospectre_v2 would be sufficient to get back full > performance. The performance penalty comes from retpoline penalizing indirect branch predictions in kernel. With nospectre_v2, retpoline is disabled so you should get all the performance back from spectre mitigation. This does not disable kernel page table isolation for meltdown mitigation, which also needs to be turned off if you want to get the full performance back. That's somewhat beyond the scope of this doc on Spectre. > > And anyway, I would like to compile the kernel to not need that command-line > option, > so I am still interesting in what compile options need to be set to what > values... > If you just want to disable spectre mitigation, setting CONFIG_RETPOLINE=n should do the trick. If you also want to disable meltdown mitigation, set CONFIG_PAGE_TABLE_ISOLATION=n. Thanks. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/31/2018 8:22 AM, Ben Greear wrote: On 12/21/2018 05:17 PM, Tim Chen wrote: On 12/21/18 1:59 PM, Ben Greear wrote: On 12/21/18 9:44 AM, Tim Chen wrote: Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while. But we want to send it out for everyone to take a look. Can you add a section on how to compile out all mitigations that have anything beyond negligible performance impact for those running systems where performance is more important than security? If you don't worry about security and performance is paramount, then boot with "nospectre_v2". That's explained in the document. There seem to be lots of different variants of this type of problem. It was not clear to me that just doing nospectre_v2 would be sufficient to get back full performance. And anyway, I would like to compile the kernel to not need that command-line option, so I am still interesting in what compile options need to be set to what values... the cloud people call this scenario "single tenant".. there might be different "users" in the uid sense, but they're all owned by the same folks it would not be insane to make a CONFIG_SINGLE_TENANT kind of option under which we can group thse kind of things (and likely others)
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/21/2018 05:17 PM, Tim Chen wrote: On 12/21/18 1:59 PM, Ben Greear wrote: On 12/21/18 9:44 AM, Tim Chen wrote: Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while. But we want to send it out for everyone to take a look. Can you add a section on how to compile out all mitigations that have anything beyond negligible performance impact for those running systems where performance is more important than security? If you don't worry about security and performance is paramount, then boot with "nospectre_v2". That's explained in the document. There seem to be lots of different variants of this type of problem. It was not clear to me that just doing nospectre_v2 would be sufficient to get back full performance. And anyway, I would like to compile the kernel to not need that command-line option, so I am still interesting in what compile options need to be set to what values... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Fri, 21 Dec 2018 09:44:44 -0800 Tim Chen wrote: > Andi and I have made an update to our draft of the Spectre admin guide. > We may be out on Christmas vacation for a while. But we want to > send it out for everyone to take a look. > > Thanks. > > Tim > > From: Andi Kleen > > There are no document in admin guides describing > Spectre v1 and v2 side channels and their mitigations > in Linux. > > Create a document to describe Spectre and the mitigation > methods used in the kernel. > > Signed-off-by: Andi Kleen > Signed-off-by: Tim Chen > --- > Documentation/admin-guide/spectre.rst | 502 > ++ > 1 file changed, 502 insertions(+) > create mode 100644 Documentation/admin-guide/spectre.rst I only saw this now, seems I wasn't copied... I'll take a deeper look, but I have a couple of meta comments: - This could arguably go in the security book rather than the admin guide. I don't really have a strong opinion on which is right at the moment, but others might. - Wherever it ends up, can you also please add it to the appropriate index.rst file so it actually gets built with the rest of the docs? Thanks, jon
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote: > + > +4. Kernel sandbox attacking kernel > +^^ > + > +The kernel has support for running user-supplied programs within the > +kernel. Specific rules (such as bounds checking) are enforced on these > +programs by the kernel to ensure that they do not violate access controls. > + > +eBPF is a kernel sub-system that uses user-supplied program > +to execute JITed untrusted byte code inside the kernel. eBPF is used > +for manipulating and examining network packets, examining system call > +parameters for sand boxes and other uses. > + > +A malicious local process could upload and trigger an malicious > +eBPF script to the kernel, with the script attacking the kernel > +using variant 1 or 2 and reading memory. Above is not correct. The exploit for var2 does not load bpf progs into kernel. Instead the bpf interpreter is speculatively executing bpf prog that was never loaded. Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder to exploit. Same goes for other in kernel interpreters and state machines. > + > +Necessary Prerequisites: > +1. Malicious local process > +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets > +on the same machine. This is not quite correct either. Var 1 could have been exploited with and without JIT. Also above sounds like that var1 is still exploitable through bpf which is not the case.
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/21/18 1:59 PM, Ben Greear wrote: > On 12/21/18 9:44 AM, Tim Chen wrote: >> Thomas, >> >> Andi and I have made an update to our draft of the Spectre admin guide. >> We may be out on Christmas vacation for a while. But we want to >> send it out for everyone to take a look. > > Can you add a section on how to compile out all mitigations that have anything > beyond negligible performance impact for those running systems where > performance > is more important than security? > If you don't worry about security and performance is paramount, then boot with "nospectre_v2". That's explained in the document. Tim
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On 12/21/18 9:44 AM, Tim Chen wrote: Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while. But we want to send it out for everyone to take a look. Can you add a section on how to compile out all mitigations that have anything beyond negligible performance impact for those running systems where performance is more important than security? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
[PATCH] x86/speculation: Add document to describe Spectre and its mitigations
Thomas,
Andi and I have made an update to our draft of the Spectre admin guide.
We may be out on Christmas vacation for a while. But we want to
send it out for everyone to take a look.
Thanks.
Tim
From: Andi Kleen
There are no document in admin guides describing
Spectre v1 and v2 side channels and their mitigations
in Linux.
Create a document to describe Spectre and the mitigation
methods used in the kernel.
Signed-off-by: Andi Kleen
Signed-off-by: Tim Chen
---
Documentation/admin-guide/spectre.rst | 502 ++
1 file changed, 502 insertions(+)
create mode 100644 Documentation/admin-guide/spectre.rst
diff --git a/Documentation/admin-guide/spectre.rst
b/Documentation/admin-guide/spectre.rst
new file mode 100644
index 000..0ba708e
--- /dev/null
+++ b/Documentation/admin-guide/spectre.rst
@@ -0,0 +1,502 @@
+Spectre side channels
+=
+
+Spectre is a class of side channel attacks against modern CPUs that
+exploit branch prediction and speculative execution to read memory,
+possibly bypassing access controls. These exploits do not modify memory.
+
+This document covers Spectre variant 1 and 2.
+
+Affected processors
+---
+
+The vulnerability affects a wide range of modern high performance
+processors, since most modern high speed processors use branch prediction
+and speculative execution.
+
+The following CPUs are vulnerable:
+
+- Intel Core, Atom, Pentium, Xeon CPUs
+- AMD CPUs like Phenom, EPYC, Zen.
+- IBM processors like POWER and zSeries
+- Higher end ARM processors
+- Apple CPUs
+- Higher end MIPS CPUs
+- Likely most other high performance CPUs. Contact your CPU vendor for
details.
+
+This document describes the mitigations on Intel CPUs. Mitigations
+on other architectures may be different.
+
+Related CVEs
+
+
+The following CVE entries describe Spectre variants:
+
+ = === ==
+ CVE-2017-5753 Bounds check bypass Spectre-V1
+ CVE-2017-5715 Branch target injection Spectre-V2
+
+Problem
+---
+
+CPUs have shared caches, such as buffers for branch prediction, which are
+later used to guide speculative execution. These buffers are not flushed
+over context switches or change in privilege levels. Malicious software
+might influence these buffers and trigger specific speculative execution
+in the kernel or different user processes. This speculative execution can
+then be used to read data in memory and cause side effects, such as displacing
+data in a data cache. The side effect can then later be measured by the
+malicious software, and used to determine the memory values read speculatively.
+
+Spectre attacks allow tricking other software to disclose
+values in their memory.
+
+In a typical Spectre variant 1 attack, the attacker passes an parameter
+to a victim. The victim boundary checks the parameter and rejects illegal
+values. However due to speculation over branch prediction the code path
+for correct values might be speculatively executed, then reference memory
+controlled by the input parameter and leave measurable side effects in
+the caches. The attacker could then measure these side effects
+and determine the leaked value.
+
+There are some extensions of Spectre variant 1 attacks for reading
+data over the network, see [2]. However the attacks are very
+difficult, low bandwidth and fragile and considered low risk.
+
+For Spectre variant 2 the attacker poisons the indirect branch
+predictors of the CPU. Then control is passed to the victim, which
+executes indirect branches. Due to the poisoned branch predictor data
+the CPU can speculatively execute arbitrary code in the victim's
+address space, such as a code sequence ("disclosure gadget") that
+reads arbitrary data on some input parameter and causes a measurable
+cache side effect based on the value. The attacker can then measure
+this side effect after gaining control again and determine the value.
+
+The most useful gadgets take an attacker-controlled input parameter so
+that the memory read can be controlled. Gadgets without input parameters
+might be possible, but the attacker would have very little control over what
+memory can be read, reducing the risk of the attack revealing useful data.
+
+Attack scenarios
+
+
+Here is a list of attack scenarios that have been anticipated, but
+may not cover all possible attack patterns. Reduing the occurrences of
+attack pre-requisites listed can reduce the risk that a spectre attack
+leaks useful data.
+
+1. Local User process attacking kernel
+^^
+
+Code in system calls often enforces access controls with conditional
+branches based on user data. These branches are potential targets for
+Spectre v2 exploits. Interrupt handlers, on the other hand, rarely
+handle user data or enforce access controls, which makes them unlikely
+exploit targets.
+
+For typical variant
