Eben Upton Explains Why Raspberry Pi Isn't Vulnerable To Spectre Or Meltdown (raspberrypi.org)
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."
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."
What you qualify as "toys" are more powerful than the computers we used when I was in college in the mid-1990's.
#DeleteFacebook
Care to point out where in Arms white paper it mentions the a7 or a53 cores being affected by Spectre?
https://developer.arm.com/support/security-update
Except that ARM doesn’t list the A7 or A53 as vulnerable.
https://developer.arm.com/supp...
So Eben knows just as much as ARM does.
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.
I don't know the exact number, of course, but I know that a raspberry pi is at MINIMUM a thousand times more powerful than computers that took us to the moon. So like, what fucking ever.
Don't really know if a list is practical. As you Say there are a lot of ARM based CPUs.
However most CPUs if you google the model number you can find a product page that will tell you which cores are in it. Compare the cores to ARMs list here https://developer.arm.com/support/security-update
So your example of the Texas Instruments DM3725 http://www.ti.com/product/DM3725 contains an Arm A-8 core which is affected by variant 1 and 2 of spectre.
Raspberry PIs and equivalents are toys.
Raspberry PI isn't a CPU. It is a single-board-computer designed for computer-science education and for rapid prototyping of embedded systems. The CPU in question is the Cortex A53 processor, which according to the manufacturer's datasheet is intended as a:
High efficiency processor for a wide range of applications in mobile, DTV, automotive, networking, storage, aerospace, and more.
This doesn't sound like a toy. It sounds like it is meant to be simple and efficient to integrate into industrial designs. That probably means that power consumption is a higher priority than squeezing the most performance out of the chip, which in turn means less aggressive use of speculative execution to keep as much of the chip working at any given time as possible.
So not being as vulnerable to this particular side channel attack isn't the result of the forethought of the Raspberry Pi's designers, or or Broadcom or ARM Holdings. It's the result of the intended applications of the CPU.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
It doesn't use an Intel cpu
True for "Meltdown", which only breaks Intel CPUs. But "Spectre" also breaks some AMD and ARM processors.
Fortunately, the particular ARM cores in the Raspbery Pi are also NOT doing the thing that lets Spectre break them.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
I don't read your sig. Why are you reading mine?
And uninstall your web browser, Since almost every web page contains javascript that gets downloaded and run as "local code". Spectre can work via javascript.
SnapDragon CPUs are affected by spectre as well. Quallcomm just recently verified this.
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 tell their machine is 5% to 20% slower... b/c their quad core CPU is idling below 10% anyway.
The trend lately is towards low power chips for users at all levels -- even data centers... and trending towards mobility for users. Phones, tablets, chromebooks, laptops that are basically tablets, etc.
If I have to decide between a fat cache that doesn't get flushed in the name of security vs speculative processing... for whatever spectre or related exploit may be around the corner, I think I might rather have the cache. If every time a file server randomly accesses a database, their entire cache is flushed to protect against a bug... I could see where turning off branch prediction if possible might be a better solution than flushing the cache. A cache miss can be huge -- many orders of magnitude longer than waiting several cycles to execute something that wasn't predicted, but was pre-fetched at least.
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".
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.
Nullius in verba
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...
http://www.earth.org.uk/_off-g...
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
http://m.earth.org.uk/
If you learn to make a solution on a low performance device then you will become a better coder less prone to make inefficient solutions.
You can always make something that works, but to do something efficient takes skill.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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_ important for a single user desktop or laptop, it's _very_ important for phones and tablets that should have protection between apps, and critically important for any servers.
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 a security risk *might* be.
The other side of this is that both Mozilla and Google have released SPECTRE-hardened web browsers, so there's that.
You are not alone. This is not normal. None of this is normal.
All out-of-order processors perform speculation. You can't fill an out-of-order pipeline usefully without it and the power, area, and complexity overheads of out-of-order designs are huge so no one is crazy enough to build an out-of-order design that throws away most of the benefit by not doing any speculation. A number of in-order processors do as well, because any pipelined processor that doesn't do some speculative execution is going to have pipeline bubbles and lose a good 20% of its maximum throughput.
The Raspberry Pi uses in-order cores. I don't remember much about the ancient ARM11 on the original, but the newer ones use A7 and A53 cores, which both have very similar pipeline designs. They do perform speculative execution (and they definitely do perform branch prediction - the only pipelined processors that don't are specialised things like DSPs and GPUs), but it appears that the in-flight instruction are cancelled sufficiently early that you never see different execution times depending on which speculative path way taken (only differences between wether speculative execution was correct not).
The core of the Spectre attacks is that you can have speculative execution that has data-dependent timings and then use the timing to tell which of the paths was executed and therefore what the data was. This is generally harder to exploit on in-order processors, because instructions are still executing in the correct order and you typically only have 7-8 cycles between starting to speculate and the instructions being cancelled. That's generally not long enough to satisfy an L1 miss, so it's fairly common to wait before doing an L2 fetch until you know that the instructions won't be cancelled.
I am TheRaven on Soylent News