Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Operating Systems Privacy Security Software Hardware Technology

Eben Upton Explains Why Raspberry Pi Isn't Vulnerable To Spectre Or Meltdown (raspberrypi.org) 116

Raspberry Pi founder and CEO Eben Upton says the Raspberry Pi isn't susceptible to the "Spectre" or "Meltdown" vulnerabilities because of the particular ARM cores they use. "Spectre allows an attacker to bypass software checks to read data from arbitrary locations in the current address space; Meltdown allows an attacker to read data from arbitrary locations in the operating system kernel's address space (which should normally be inaccessible to user programs)," Upton writes. He goes on to provide a "primer on some concepts in modern processor design" and "illustrate these concepts using simple programs in Python syntax..."

In conclusion: "Modern processors go to great lengths to preserve the abstraction that they are in-order scalar machines that access memory directly, while in fact using a host of techniques including caching, instruction reordering, and speculation to deliver much higher performance than a simple processor could hope to achieve," writes Upton. "Meltdown and Spectre are examples of what happens when we reason about security in the context of that abstraction, and then encounter minor discrepancies between the abstraction and reality. 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."
This discussion has been archived. No new comments can be posted.

Eben Upton Explains Why Raspberry Pi Isn't Vulnerable To Spectre Or Meltdown

Comments Filter:
  • In other words (Score:5, Informative)

    by Anonymous Coward on Friday January 05, 2018 @06:50PM (#55872069)

    You wanted a cheap computer, so we picked a cheap CPU that doesn't do fancy-schmancy stuff like trying to guess what you will do next.

    In other news, my abacus never has a battery fire.

    • Speculative execution requires the CPU to do operations which it might be called upon to do in the future, then throw away the results if it turns out the code doesn't call for that operation. There's got to be an energy cost associated with that since you're making it do a bunch of operations it doesn't need to do. ARM SoCs are mostly used on mobile devices whose only power source is a battery. So it makes sense that they wouldn't incorporate energy-wasting "features" like speculation.
      • by Ramze ( 640788 )

        considering what little CPU percentage is used by the average PC user, there may be an argument for desktops and laptops not needing it either.... Maybe even for data centers where large caches are more important than branch predictions.

        I know, I know... Insanity! Branch prediction is like... 75% to 99% correct, so it's not that much of a waste... and pipelines are long... but, Intel just helped put out a patch that wipes cache when switching between user mode and kernel mode and your average user can't

      • There's got to be an energy cost associated with that since you're making it do a bunch of operations it doesn't need to do.

        True, to an extent, but not entirely. The difference in power consumption between a CPU executing instructions and a CPU in a pipeline stall is fairly small. The difference between a CPU executing instructions and in a sleep state is a lot higher, so you get better power efficiency if you finish fast and go to sleep.

        On wide out-of-order pipelines, you're using a lot of energy just to have the scheduler and register rename units powered. This is why the low-end ARM cores get better performance per Wat

  • by mspohr ( 589790 ) on Friday January 05, 2018 @07:27PM (#55872305)

    With all the hype and panic about these vulnerabilities, it was refreshing to read Eben's clear, detailed tutorial on processor architecture and how these exploits work (and why the RPi isn't vulnerable).
    Highly recommend reading the article.

  • "Oh! Is THIS ARM chip vulnerable? Oh, NNNNNOOOO...." Everyone seems to have lost perspective here. 1) In order for you to be "vulnerable", you must be running some kind of malware. If you're running malware, you are already fucked with a sand-paper dildo. 2) Given #1, coupled with the astounding number/variety of destructive forms of malware extant, it is ludicrous to give more than a nano-second's consideration (as a basic user or admin) to this. 3) Does anyone have any idea of how difficult it is to lever
    • 3) Does anyone have any idea of how difficult it is to leverage this particular vulnerability to do something useful?

      NVD doesn't, yet. They have a big banner that says "undergoing analysis".

      https://nvd.nist.gov/vuln/deta... [nist.gov]

    • Re:You guys... (Score:4, Informative)

      by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Friday January 05, 2018 @11:39PM (#55873405) Homepage Journal

      Everyone seems to have lost perspective here. 1) In order for you to be "vulnerable", you must be running some kind of malware. If you're running malware, you are already fucked with a sand-paper dildo.

      It would be surprising if the average user didn't encounter malicious code, because malicious Javascript is a thing. At least one of these attacks can be made through your browser. How are you enjoying your anal sanding?

    • 1) In order for you to be "vulnerable", you must be running some kind of malware. If you're running malware, you are already fucked with a sand-paper dildo.

      Depends. If I run malware on my Mac and it is 100% limited to the single user that it's running on, then I'm fucked. Because the single user (me) is all I care about. If I run malware on a cloud server that is 100% limited to the single user that it's running on, then _I_ am still fucked, but everyone else on the server is safe. If I ran malware on my iPhone, software isn't supposed to be able to access anything outside that app, so I should be safe even with malware.

      So fixing this is not _that_ importan

    • For SPECTRE, the nature of the attack means that programs you expect to be sandboxed in VMs, such as Javascript scripts, may be able to read data outside of their sandboxes if the VM does not specifically address it. So if someone's running a web browser on a SPECTRE-vulnerable ARM CPU, then they're vulnerable if they browse the web if the browser hasn't been SPECTRE hardened.

      So saying "You must be running some kind of malware" is misleading. Types of software you run that you would not normally consider

  • Raspberry PI 3 is far from a toy. The main thing is to install the Raspbian Lite without GUI desktop. Most of the computing "power" is spent on handling of the HD, 4K, 8K, etc. display.

    I installed Apache 2, PHP 7, SSH, SFTP on one RPI3 and MySQL database on another. This system is incredibly stable and quite fast. I think of moving to self-hosting with this setup. It practically does not consume any electricity.

    I realize now that it does not requite too much computing power to send HTML files and even
    • by DamonHD ( 794830 )

      I run a similar setup (ie my entire primary server set including HTTP, NTP, DNS, etc) on an RPi2.

      Does its job very well and uses only 1W most of the time enabling me to keep them off-grid:

      http://www.earth.org.uk/note-o... [earth.org.uk]

      http://www.earth.org.uk/_off-g... [earth.org.uk]

      I see various people pissing all over the RPis here, but they really are remarkable, and bigger is not always better. It depends on the application.

      Rgds

      Damon

    • I installed Apache 2, PHP 7, SSH, SFTP on one RPI3 and MySQL database on another.

      I've experimented with all of that. Performance was... well, let's just say it was shit. The lack of memory is the big problem. There just isn't enough. This is why I got a Pine A64+. Which, of course, is arm64 and probably vulnerable :p

      I do use an original raspi as a serial redirector, which is about its speed. I might swap that out for an esp8266 though, which can handle that job. I also have a zero w which I plan to mount on my dead cat, but I have many projects ahead of that one.

  • by tlambert ( 566799 ) on Saturday January 06, 2018 @02:02AM (#55873883)

    No instruction pipeline cache == feature.

    Yeah all ARM7 cores have that "security feature".

    I hear PC-XT's are making a comeback, because most malware won't fit in 640K any more.

    So having only 640K is a "security feature".

  • by bugs2squash ( 1132591 ) on Saturday January 06, 2018 @02:34AM (#55873971)
    That's the most accessible description of these issues that I have read about to date. Everything else has either been difficult to follow or just plain arm-waving and jargon designed to make the storyteller look all 1337.
  • This should advance the reputation of FOS Hardware further. Which can't be wrong. ... I'm starting to desperately awaits decent quality cheap FOS Hardware ARM Laptop. That would move things forward in this department.

  • Granted, it might not be affected by the two cpu bugs, but they've yet to fix the bandwidth starved bus.

"It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost

Working...