6 ms·

This covers both Meltdown and Spectre. > Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors

This covers both Meltdown and Spectre. > Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use. The reason why Spectre is not a problem is because there is no branch predictor in these simpler arm cores. Instructions are processed in parallel when possible, but not before dependencies, including branch decisions. EDIT: under "What is speculation?" branch prediction is described. Then in the conclusion: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."

tptacek 9y ago
I'm not arguing that R-Pi's are vulnerable to Spectre.
- ploxiln 9y ago
  You're arguing that this article does not cover Spectre. It does ... it just doesn't have to fully describe spectre to show why the raspi is not affected.
- deleted 9y ago
  [deleted]
loeg 9y ago
There is almost certainly a branch predictor even in these simple ARM cores.
- ploxiln 9y ago
  Ah, that's good to know ... a comment below mentioned a "BTAC" (branch target access cache). Is it just used for getting instructions into the L1i cache then?
- piinbinary 9y ago
  (Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?
  - quasse 9y ago
    Avoiding having to empty the instruction pipeline when a branch happens and restart. My favorite simple video explaining pipeline is still this old Apple one from back in the early 2000s: https://youtu.be/PKF9GOE2q38?t=237 https://youtu.be/PKF9GOE2q38?t=237
  - cwzwarich 9y ago
    It is used to determine which instructions to fetch and decode, so that you don't have to wait until the branch is resolved to query the instruction cache, instruction TLB, MMU, DRAM, etc. If the branch was mispredicted, you have to stall to wait for this to complete.
  - msbarnett 9y ago
    In a pipelined CPU, you want to start the memory fetches for which instructions to next feed into the instruction decoder, before the branch instruction has finished the execute stage. Otherwise every branch incurs a pipeline bubble.
    - PeterisP 9y ago
      If you're doing speculative memory fetches, wouldn't that also leave a measurable impact on the cache? Simply instead of MOV AX, [something that depends on secret value] as in the original Meltdown paper you'd need to use JMP [something that depends on secret value] to trigger the memory fetch in a branch that's not going to be used.
      - msbarnett 9y ago
        Yeah, it's not 100% obvious to me that you couldn't stage some variant of Spectre against even this more limited form of speculation. In the comments on the article the author argues: "Why don’t speculative instruction (and data) fetches introduce a vulnerability? Because unlike speculative execution they don’t lead to a separation between a read instruction and the process (whether a hardware page fault or a software bounds check) that determines whether that read instruction is allowed." but that would seem to be confusing the details of Spectre with Meltdown (which is happening a lot right now). Spectre doesn't depend on unauthorized reads succeeding.
- phkahler 9y ago
  There's no reason to predict a branch if you're not going to execute speculatively. I need to re-read the papers but I think the real problem isn't even speculative execution but allowing speculative cache changes. The notion that "gadgets" didn't even need to return properly was both amusing and eye opening for me. It doesn't matter because the result will be flushed anyway! ;-)
  - bazizbaziz 9y ago
    > There's no reason to predict a branch if you're not going to execute speculatively. Not quite. Branch prediction is typically used on non-speculative architectures in order to avoid pipeline bubbles. (You could argue that pipelining is a form of speculation) Here is the branch prediction documentation for one of the processors they claim is not vulnerable. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1001575.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... Whether or not they're vulnerable has more to do with how their pipeline is structured. It's possible for an architecture to be vulnerable if a request to the load store unit can be done within the window between post-branch instruction fetch/exec and a branch resolution. Eyeballing the pipeline diagram from the above docs, it looks like you can maybe get a request to the LSU off before the branch resolves. dramatic music
  - cwzwarich 9y ago
    In an in-order CPU, you can still use a branch predictor to predict what to fetch and decode, so that you don't stall waiting for instruction fetch to finish after you resolve the branch. In practice, advanced in-order designs contain more local reordering mechanisms, e.g. in the load/store unit, but they lack the unified global abstraction of a reorder buffer. The most successful timing attacks involve a mis-speculated load, so they wouldn't apply to these mechanisms, but it's not completely out of the question that they are also an effective side-channel.
  - kevin_thibedeau 9y ago
    Low end ARM parts keep track of branches to avoid purging cached pages that will be likely be needed soon. That allows them to have decent performance when executing from flash.
- bunderbunder 9y ago
  Yes. The reference manuals for the cores indicate that they all do. rpi 1: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/ddi0301h_arm1176jzfs_r0p7_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/dd... rpi 2: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DDI0464D_cortex_a7_mpcore_r0p3_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DD... rpi 3: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DDI0500D_cortex_a53_r0p2_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DD... As others have indicated further down, though, it won't open up much of a vulnerability unless they are speculatively fetching memory.
makomk 9y ago
A lot of the cheaper Pi-like boards also aren't affected for the same reason, as are lower-end Android phones. The articles claiming it affected every modern CPU were basically mistaken. It was an easy mistake to make, given that ARM's announcement only listed the cores that were affected and had a little note saying everything not listed was unaffected by both Meltdown and Spectre. (There is precisely one ARM-designed core that is affected by Meltdown, a high-end one so new that no chips based on it have been released yet.)
- davrosthedalek 9y ago
  One could argue that CPUs without branch prediction are not modern in the sense of "modern, state of the art design". The fact that they still produce,e.g. 8051, even "new" overall designs, doesn't make the 8051 modern.
  - zzzcpan 9y ago
    Branch prediction is neither new nor modern. Modern state of the art design doesn't actually do branch prediction in hardware at all. I mean look at all the ideas from VLIW architecture, no hardware - no problems.
    - haimez 9y ago
      You're being pretty silly by zeroing in on the word modern and then using an equally silly redefinition of it yourself. Branch prediction isn't new, you're right. But VLIW instructions are equally unmodern and are entirely orthogonal to speculative execution. Sufficiently smart compilers are also no substitute for runtime analysis.
      - harlanji 9y ago
        My CS book (Bryant and O'Hallaron, 2003, p. 399) says Control Data 6600 in 1964 was the first processor w out of order executuon, considered exotic until RS/6000 by IBM in 1990/PowerPC 601 in 1993.
katastic 9y ago
Old Atoms also don't have a branch predictor. The new ones might? IIRC, they were basically "low power" versions of the desktop CPUs by ripping out all the expensive branch prediction / out-of-order speculation parts. I used to know this more because I was reading intentionally on it, but old age and years passing kind of rots the memory. [edit] Yep: >every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013. http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/ http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... So "every Intel CPU" is correct enough for the general public to scare most people (as it is potentially a huge problem), but it's incorrect in the sense it doesn't apply to ALL Intel CPUs. Atoms are very popular in netbooks. (And the Itaniums exception we can ignore because a handful of machines across the entire planet are running them.)
deleted 9y ago
[deleted]

tptacek 9y ago

I'm not arguing that R-Pi's are vulnerable to Spectre.

ploxiln 9y ago
You're arguing that this article does not cover Spectre. It does ... it just doesn't have to fully describe spectre to show why the raspi is not affected.
deleted 9y ago
[deleted]

loeg 9y ago

There is almost certainly a branch predictor even in these simple ARM cores.

ploxiln 9y ago
Ah, that's good to know ... a comment below mentioned a "BTAC" (branch target access cache). Is it just used for getting instructions into the L1i cache then?
piinbinary 9y ago
(Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?
- quasse 9y ago
  Avoiding having to empty the instruction pipeline when a branch happens and restart. My favorite simple video explaining pipeline is still this old Apple one from back in the early 2000s: https://youtu.be/PKF9GOE2q38?t=237 https://youtu.be/PKF9GOE2q38?t=237
- cwzwarich 9y ago
  It is used to determine which instructions to fetch and decode, so that you don't have to wait until the branch is resolved to query the instruction cache, instruction TLB, MMU, DRAM, etc. If the branch was mispredicted, you have to stall to wait for this to complete.
- msbarnett 9y ago
  In a pipelined CPU, you want to start the memory fetches for which instructions to next feed into the instruction decoder, before the branch instruction has finished the execute stage. Otherwise every branch incurs a pipeline bubble.
  - PeterisP 9y ago
    If you're doing speculative memory fetches, wouldn't that also leave a measurable impact on the cache? Simply instead of MOV AX, [something that depends on secret value] as in the original Meltdown paper you'd need to use JMP [something that depends on secret value] to trigger the memory fetch in a branch that's not going to be used.
    - msbarnett 9y ago
      Yeah, it's not 100% obvious to me that you couldn't stage some variant of Spectre against even this more limited form of speculation. In the comments on the article the author argues: "Why don’t speculative instruction (and data) fetches introduce a vulnerability? Because unlike speculative execution they don’t lead to a separation between a read instruction and the process (whether a hardware page fault or a software bounds check) that determines whether that read instruction is allowed." but that would seem to be confusing the details of Spectre with Meltdown (which is happening a lot right now). Spectre doesn't depend on unauthorized reads succeeding.
phkahler 9y ago
There's no reason to predict a branch if you're not going to execute speculatively. I need to re-read the papers but I think the real problem isn't even speculative execution but allowing speculative cache changes. The notion that "gadgets" didn't even need to return properly was both amusing and eye opening for me. It doesn't matter because the result will be flushed anyway! ;-)
- bazizbaziz 9y ago
  > There's no reason to predict a branch if you're not going to execute speculatively. Not quite. Branch prediction is typically used on non-speculative architectures in order to avoid pipeline bubbles. (You could argue that pipelining is a form of speculation) Here is the branch prediction documentation for one of the processors they claim is not vulnerable. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1001575.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... Whether or not they're vulnerable has more to do with how their pipeline is structured. It's possible for an architecture to be vulnerable if a request to the load store unit can be done within the window between post-branch instruction fetch/exec and a branch resolution. Eyeballing the pipeline diagram from the above docs, it looks like you can maybe get a request to the LSU off before the branch resolves. dramatic music
- cwzwarich 9y ago
  In an in-order CPU, you can still use a branch predictor to predict what to fetch and decode, so that you don't stall waiting for instruction fetch to finish after you resolve the branch. In practice, advanced in-order designs contain more local reordering mechanisms, e.g. in the load/store unit, but they lack the unified global abstraction of a reorder buffer. The most successful timing attacks involve a mis-speculated load, so they wouldn't apply to these mechanisms, but it's not completely out of the question that they are also an effective side-channel.
- kevin_thibedeau 9y ago
  Low end ARM parts keep track of branches to avoid purging cached pages that will be likely be needed soon. That allows them to have decent performance when executing from flash.
bunderbunder 9y ago
Yes. The reference manuals for the cores indicate that they all do. rpi 1: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/ddi0301h_arm1176jzfs_r0p7_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/dd... rpi 2: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DDI0464D_cortex_a7_mpcore_r0p3_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DD... rpi 3: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DDI0500D_cortex_a53_r0p2_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DD... As others have indicated further down, though, it won't open up much of a vulnerability unless they are speculatively fetching memory.

makomk 9y ago

A lot of the cheaper Pi-like boards also aren't affected for the same reason, as are lower-end Android phones. The articles claiming it affected every modern CPU were basically mistaken. It was an easy mistake to make, given that ARM's announcement only listed the cores that were affected and had a little note saying everything not listed was unaffected by both Meltdown and Spectre. (There is precisely one ARM-designed core that is affected by Meltdown, a high-end one so new that no chips based on it have been released yet.)

davrosthedalek 9y ago
One could argue that CPUs without branch prediction are not modern in the sense of "modern, state of the art design". The fact that they still produce,e.g. 8051, even "new" overall designs, doesn't make the 8051 modern.
- zzzcpan 9y ago
  Branch prediction is neither new nor modern. Modern state of the art design doesn't actually do branch prediction in hardware at all. I mean look at all the ideas from VLIW architecture, no hardware - no problems.
  - haimez 9y ago
    You're being pretty silly by zeroing in on the word modern and then using an equally silly redefinition of it yourself. Branch prediction isn't new, you're right. But VLIW instructions are equally unmodern and are entirely orthogonal to speculative execution. Sufficiently smart compilers are also no substitute for runtime analysis.
    - harlanji 9y ago
      My CS book (Bryant and O'Hallaron, 2003, p. 399) says Control Data 6600 in 1964 was the first processor w out of order executuon, considered exotic until RS/6000 by IBM in 1990/PowerPC 601 in 1993.

katastic 9y ago

Old Atoms also don't have a branch predictor. The new ones might? IIRC, they were basically "low power" versions of the desktop CPUs by ripping out all the expensive branch prediction / out-of-order speculation parts. I used to know this more because I was reading intentionally on it, but old age and years passing kind of rots the memory. [edit] Yep: >every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013. http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/ http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... So "every Intel CPU" is correct enough for the general public to scare most people (as it is potentially a huge problem), but it's incorrect in the sense it doesn't apply to ALL Intel CPUs. Atoms are very popular in netbooks. (And the Itaniums exception we can ignore because a handful of machines across the entire planet are running them.)

deleted 9y ago

[deleted]