Slashdot Mirror
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."
Poop in my mouth.
...are listed as vulnerable by ARM Holdings in their whitepaper on Spectre.
Raspberry Pi devs are misinformed.
Raspberry PIs and equivalents are toys. Nothing more. Anyone seriously believing that a hobbyist's plaything could or should be used in stead of a real computer should be laughed off stage. That will be all.
It doesn't use an Intel cpu
I wonder if there will be a more concise list of all the CPU and part numbers that are susceptible to Spectre and Meltdown.
There are so many ARM based CPUs out there that it would be good to know if my IOT device is a concern.... Or tablet... Or phone.... I guess now more than ever it will be good for google play to verify all the updates that go into the play store...
I also wonder if there will be possible future weird attach vectors for Amazon Echo (Texas Instruments DM3725 on older models), NEST (Sitara ARM), etc...
is a feature.
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.
It's a bona fide low-power computer that is suited for some computing tasks but is not a replacement for a laptop or desktop PC.
There is a difference.
Comparing a PC to a Pi is like comparing a professional-grade bicycle with a $50 kid's bike. Both get the job done and both are built to last for years, but one has a lot more features than the other.
It is NOT comparing a professional-grade bicycle with a toy bicycle that Ken and Barbie dolls can ride around on.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
...because nobody in their right mind does online banking on a RasPi.
Those SD cards will go corrupt if you just look at them!
Anyone that panics about an issue that requires LOCAL CODE to run needs to check their six.
Seriously, turn off remote Admin, your Guest account and watch your shares.
When a SnapDragon Flaw comes up, then you can panic...
to bad they dump all IO on the usb 2.0 bus so no gig-e hell not even full 100M much less with any disk io at the same time.
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.
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?
"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 leverage this particular vulnerability to do something useful? Especially given #2 above. Crikey - the Panic Parade(TM) must go on, I guess.
The Raspberry Pi is known for having one of the slowest CPUs in the world.
Who cares if it doesn't suffer from a 20% slowdown? It's already slow as fuck.
"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.
There's a book about this called leaky abstractions. This phenomena is nothing new.
That RPi hardware is an obsolete crap.
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.
People complain about the speed of the Pi.
The Pi is designed for embedded applications and learning.
embedded applications have low memory requirements, and have programmers that know how to code to those constraints. The average Microsoft Monkey, and Java Jockey is not in that group.
The Pi makes for a great learning platform. Microsoft Monkeys and Java Jockeys can use it to build their skills and ensure their code has acceptable performance on even low resource platforms. And the hardware is cheap, so if they break it [almost impossible] they can graduate to more advanced hardware once their skills improve.
There are too many Microsoft Monkeys and Java jockeys that think bubble sort is ok, and using huge arrays is ok, since everyone has 16Gb of ram, and 4Ghz CPUs with 8 cores. This is why Windows performance is terrible, and most Java Jockeys concentrate on cursor animations instead of the core functionality of their crapplets.
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 JPGs to a network.
Raspberry PI 3 is a good hardware for learning server administration. I plan to move from MySQL to PostgreSQL. On RPI3 it is possible, on my commercial hosting service it is not possible.
So it makes sense that they wouldn't incorporate energy-wasting "features" like speculation.
It's not the "energy wasting", It's the silicon area required and the corresponding decrease in yield. You're talking about $1 processors that are cranked out in massive quantity for the lowest possible price. More stuff on the SOC means more cost all around. At the next step down from here, the virtual memory unit is ditched, again not for energy consumed but because it's complex and increases die size and cost.
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
See subject: They did so early (last night) even for Win7 users & I applied it - & may sound strange but I'm FASTER vs. before it seems (though I should be slower, right?) + all my programs work just fine!
* Whatever they did ontop of this kernelmode separation between usermode apps & kernelmode I/O drivers MIGHT be the difference but so far, I am liking it!
APK
P.S.=> I heard they weren't going to release it until next patch Tuesday 1/10/2017 but I got a ~341++ mb download of it yesterday evening via Windows Update & applied it - the above is based SOLELY on user experience (not 'formal tests') but I expected "lag" in disk defrag OR backup as both perform HEAVY disk I/O - I am NOT - they're fast as ever but overall, everything seems quicker oddly (& I am assuming it contains the patch to Process Control Block/Memmgt + Transition Lookaside Buffers (TLB) changes between usermode/kernelmode programs - why else would they release it early otherwise?)... apk
Microsoft monkey here... at least if you consider a .NET developer a Microsoft monkey. I use Intel vTune Amplifier to optimize memory usage and garbage collection as well as optimizing algorithms. I use .NET as opposed to C++ because of performance. .NET allows me to write code which automatically recompileâ(TM)s itself based on optimal CPU pipelines to reduce or eliminate unnecessary branching and cache misses related to the general shortcoming of precompiled code.
Add to that scalable implementations of RTTI via reflection allowing for annotation of the AST for intelligent module loading and Iâ(TM)m pretty pleased.
I am guessing I am not as skilled of a developer as you who clearly would understand better how to optimize code. I only have 25 years professional experience in language design, optimization, operating system design and FPGA development, so Iâ(TM)m pretty new to this whole âoehow to make fast codeâ thing... but Iâ(TM)m pretty sure there must be a .NET guy somewhere who knows how to write good code.
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.
We suffer more in our imagination than in reality. - Seneca
See subject: Formal tests (albeit on Win10 vs. 7 I use) show more SPEEDUP vs. slowdown per https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/ - salient quotes/excerpts:
"we see very similar sequential read and write results, the figures after the update are actually slightly better, though weâ(TM)re talking just a 1-2% difference here."
"Interestingly though the 4K-64 thread read and write performance is improved with the patch, the write performance here has been boosted by 17%"
CrystalBench "single thread score was increased by a percent"
"same in Blender, the update came in a fraction ahead"
"Ashes of the Singularity and here we see a small uplift in performance after the patch has been applied. Granted the 1% low result was only improved by 1.7% but still, itâ(TM)s certainly not slower"
"Battlefield 1 results and using the medium quality settings at 1080p with the GTX 1080 Ti sees similar performance before and after the patch, in fact again after the patch we see a very minor improvement"
APK
P.S.=> ONLY 4k - 16k DISK I/O performance seems adversely affected - hence my expected diskdefrag & backup to slowup here (not really seeming so but they're not exactly "FAST PROCESSES" either to begin w/ based on 'feel alone' as I noted here for me)... apk
Not bad But if code gets recompiled. there is a time lag. Optimize for the general case first, unless your code is VERY tied to a specific cpu.
If you need vtune to optimize at that level, your code is either very broken, or your cpu selection very specific.
Don't even talk to me about garbage collection. If it worked correctly, it would collect itself.
Then again, I only have 15 years in CPU design on the ARM/Intel and Motorola side, so I must be very new to this whole optimization and branch prediction thing.
Normally coders don't go into FPGA design, as they initially make horrible FPGA/Verilog designers. Selecting very poor implementations and architectures as they are stuck in "the compiler will optimize this for me" land. Synopsys Design-Compiler is good, but only as good as the start you give it. GIGO and all.
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 Watt than the higher-end ones: they simply omit a large chunk of logic that the more complex cores need.
It's also a case of return on (power / complexity) investment. A simple single-pipeline in-order core may have 8 stages. If you hit a branch and have no branch predictor, then you stall for 8 cycles waiting for an instruction. The common heuristic is that you have a branch every 7 instructions on average, so now we're seeing the pipeline getting about 50% occupancy. That's pretty bad, so you want a branch predictor. Fortunately, a simple one gives you 90% hit rates, so now you're close to being able to dispatch one instruction per cycle. The difference between 90% and 95% is a lot of complexity in the predictor, for little gain. If you can't speculatively execute all instructions (for example, no speculative memory reads or writes) then that doesn't cost you much performance because you're still speculative executing side-effect-free instructions, and you can do that with simple forwarding rather than complex register renaming.
Now compare that with a large out-of-order pipeline, where you can have almost 200 instructions in flight (the authors of the Spectre paper found cases of over 180). With a branch every 7 instructions, you need to correctly predict 25 branches in a row to get full pipeline occupancy. That's a big incentive to spend a lot of transistors on clever branch predictors and speculative execution.
I am TheRaven on Soylent News
I'll do from tomorrow, since it seems that my Raspberry III is the safest computer I have here in my room.
Granted, it might not be affected by the two cpu bugs, but they've yet to fix the bandwidth starved bus.
"Forget the engineers." -Carly Fiorina, briber of MIT Technology Review.
...because nobody in their right mind does online banking on a RasPi. Those SD cards will go corrupt if you just look at them!
They're fine for the most part (SD-cards in R-Pi's). And Raspbian being basically Debian, is totally solid. The only thing that would concern me with regards to online banking would be that the version of Chromium they ship tends to be a few versions out of date.
Aside from that, it's probably safer than most Windows boxes for online banking and almost certainly safer than using a smart-TV.