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."
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...
Then clearly we can conclude that ARM Holdings know very little about their own cores, as opposed to Raspberry Pi founder and CEO Eben Upton. /sarcasm
#DeleteFacebook
What you qualify as "toys" are more powerful than the computers we used when I was in college in the mid-1990's.
#DeleteFacebook
Would this flaw affect my arduino web server?
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.
is a feature.
And are still less powerful than your wristwatch today. What's your point?
A year ago, I replaced my home server (was Intel CPU), which runs photo, streaming, web services. with an RPI3. It is sufficient.
It's replacement will likely be another Arm64 which hopefully has more memory and USB3.
It would be very unlikely that I would go back to a power hungry Intel chip.
Last time I checked we don’t live in the 90s anymore and those computers look like mere toys compared to the CPUs of today. Laughably so when even a dinky Intel m3 is many times faster.
Clicked on the wrong moderation, so posting to undo.
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.
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.
are u german?
...because nobody in their right mind does online banking on a RasPi.
Those SD cards will go corrupt if you just look at them!
So you'll leave my goat alone for a bit?
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...
I can walk 100 times faster than a snail. Doesn’t make me an olympic athelete.
We can also clearly conclude that DontBeAMoran not only can't spell, he can't read either. He should pay more attention to what his username is telling him.
It depends what you use it for. An RP is a great for learning and for dedicated devices..... but we know it's far from being a modern desktop replacement. My "seat of my pants" feeling is that an RP3 is about as fast as a high end Pentium 3 (Circa 2000).
There are a *lot* of dedicated use devices that need much less power then a full fledged PC. The great thing is that PC technology doesn't stand still, and that a RP20 (or whatever the equivalent of an RP3 is in 15 years) will probably be as fast as today's PC.
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.
And my workstation is more than 300,000 times faster. Cool story, bro.
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.
And? The Apollo computer is an even quianter toy.
I know that a raspberry pi is at MINIMUM a thousand times more powerful than computers that took us to the moon.
So why hasn't the Pi taken us to Mars? Something is wrong with your logic.
Is this you? https://pics.onsizzle.com/aghghghhblanmuuughnom-nomnormnomnomnom-i-can-aff-thats-not-just-shit-why-6488225.png
"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.
Nah, really, not his fault. He's just using Intel chips....
Then clearly we can conclude that ARM Holdings know very little about their own cores, as opposed to Raspberry Pi founder and CEO Eben Upton. /sarcasm
Congratulations you just won the presumptuous rhetorical idiot of the year award. /sarcasm
Last time I checked we don’t live in the 90s anymore and those computers look like mere toys compared to the CPUs of today. Laughably so when even a dinky Intel m3 is many times faster.
Well, it has to be many times faster to run the toy bloatware that is Windows or Gnome.
Just like gases and cats expand to fill spaces, UI code expands to suck up all available CPU cycles. Compiz effects are the flaming GIFs of the cheesy websites of two decades ago.
Now faster and more secure than any intel cpu!!!!
Depends. What's the chip used in your Arduino setup? There's been a host of official, clones, and Arduino-like boards out there.
A (very?) few use Intel's Quark. I don't see Quark listed, but maybe Intel overlooked it, since I see another post where supposedly it has the management engine in it (which was introduced I think later so I'm somewhat surprised that small but new chip has it) which is another whole set of problems. If you have a generic Arduino, you probably don't have a Quark cpu.
Some Arduino's use the Atmel chips. I haven't heard anything listed. Though I wonder how thorough researches have been, given all the in house designed silicon these days, like Samsung's octacores.
Many Arduinos use ARM Cortex M0+ and M03. Both are not listed as vulnerable to any 3 or 4 variants out there.
If you use Beagleboard like I do (ARM Cortex-A8), it's vulnerable to the lesser issue, Spectre, so that'll likely get fixed when Linux distros update. (I've got 3 intel laptops, so those are going to Linux anyways or air gapped, plus 1 tablet, so on the latter, I'm still searching for when when Android OSs were or will be fixed, esp those -not- running the latest versions--Google is such a f*N mess).
I'm sure people that use the Pi care. I mean, based on you eloquent definition of their speed, they don't have much headroom for a performance drop.
yes it does, as long as you're russian :)
ok E-Peen Jong Un. You're cool, "bro".
not even close. It is slower than a Pentium MMX running at 250 Mhz.
That RPi hardware is an obsolete crap.
Cool story, Drumpf.
One word: Lousy programmers.
See? Most* can't even estimate their own workloads. It always takes twice as much as planned.
And then there are 'managers'... who prevent us from using assembly the way it's meant to be used. They want to *shudder* 'understand' what we write and collaborate and a fancy UI and garbage collection (there is a lot of garbage surrounding our little blue planet) and *fill in favorite hype/buzzword* using *popular piece of office software they say they can actually be productive in*. So everything has to go through compilers and various frameworks and engines and virtual machines... 10 levels of bloat. And that's why you need a hexadeca Core-i9 instead of a quad Cortex-a53...
Yes, Chris has been waiting his turn for months now!
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.
Am I missing something here? Most arduino that I know dont even have threads, nevermind processes or virtual memory. They already suffer from a vulnerability called "all user code has permission to read all system memory"
Good thing you don't need to be an olympic athlete to do useful everyday things like walk to the store.
The CPUs of today have the power to do real-time video encoding and AI, but instead of that we use them to ... browse the web. Watch YouTube. Do text chat on Slack. Upload files to Git servers. I can't remember the last time I asked my home computer to do anything that required real CPU power, except I've noticed web pages full of scripts causing the internet to slow to a crawl, because my browser is processing 100X more data than I asked for.
Give me a Pi and let me control what it does, and it'll have more than enough CPU power for most things I do. Anything I need a real CPU for, I can do on a standalone PC and don't need to worry about attacks.
What we really need are devices like the Raspberry Pi for untrusted connections (i.e. most of them), and a real PC for heavy lifting and doing private work like taxes. Configure them to send to a central set of displays, but they should not be connected to each other.
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.
I'm BeauHD, not Chris.
You don't need a full-blown server for basic web stuff. I host my website on a handful of shift registers and an NTE555.
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
Those early 90s computers aren't vulnerable to this exploit nor any IME AMT shenanigans.
But when you're just trying to run for the bus does it matter that you aren't capable of breaking a world record as long as you get there?
They are still suitable for various small embedded solutions. Not every computing task requires petaflop performance.
I'm not saying that the Raspberry Pi is the ideal solution, but sometimes the most amazing solutions comes out of implementations made on low performance devices while high performance devices instead allows for bloatware.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
In Soviet Russia Olympians makes you.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Lol whut? A quad core 1.2 ghz processor is about as fast as a 255 mhz processor from 20 years ago.
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
Wow, have never seen someone do this on slashdot in 20 years. Good for you.
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.
Neither the A7 nor the A53 were listed (though the R7 was - I was very surprised to see two realtime cores on the list of things affected by a vulnerability that explicitly relies on nondeterministic execution time). The A8 and A9 were as well, which is also surprising as they're very similar to the A7 and are in-order dual-issue cores.
I am TheRaven on Soylent News
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.
This. And even running bloated modern software, a Pi 3 or compute stick plugged into a keyboard, mouse and monitor would be sufficient for most of my day to day business and casual computing tasks. If you already have a suitable screen, the device itself plus a cheap keyboard and mouse are quite affordable too.
Cheap used laptops are sufficient for everyday tasks as well, at least after replacing the aging HDD with an SSD. But that brings the price higher than Pi 3+MicroSD+keyboard+mouse.
Our phones are powerful enough too - if only there were cheap laptop-like shells we could slot them into, and a good desktop interface it would switch into.
One of the things that hurts the Pi is that all the I/O is done through USB, and a lot of micro SD cards are not very fast - which isn't usually a big deal until you're using one as your OS drive.
Finally, clock for clock, ARM just isn't as fast as x86. It may be a 1.2GHz quad-core, but looking at MIPs, it's about the same as a mid-range P3, which is a single core. One of the reasons is in the TFA - the Pi doesn't do speculative branching like P3 does. My guess is that for anything single-threaded, you're probably looking at something more like Pentium MMX performance levels.
Overall, it's hard to say how the Pi stacks up. A lot will depend on what you are trying to do with it. If you're trying to use it as a desktop, you'll find it quite a bit slower than a higher-end P3 system, as the P3 will have the benefit of a faster hard drive, dedicated GPU, ethernet not hanging off the USB bus, etc. For other things like heavy number crunching it may be more comparable.
It might if the bus is 100s of feet away.