Boffins find if you torture AMD Zen+, Zen 2 CPUs enough, they are vulnerable to Meltdown-like attack Computer scientists at TU Dresden in Germany have found that AMD's Zen processor family is vulnerable to a data-bothering Meltdown-like attack after all. Exploiting this weakness is an academic exercise, it seems; there are more practical and easier ways for malware and malicious users to interfere with systems. If anything, …
"Unlike the previous AMD vulnerabilities, the flaw we report is the first flaw that proves that it is possible to force an illegal data flow between microarchitectural elements."
?????? force an illegal data flow ????? ..... I don't think so, meine Herren, whenever 'tis much more just as an invite to party somewhat differently elsewhere ‽ .
However, whenever it may be both, is it something else altogether different again and one enters into quantum communications fields of metaphysical virtual endeavour. ‽ .
And revealed here in a brace of possible questions rather than shared as blunt statements of fact to energise and welcome critical strategic peer review rather than activate the doomed venal opposition and hubristic mutterings and utterings of the Doubting Thomas and Thomasina Brigades representing the seriously ill-informed and the serially intellectually challenged and the almost criminally extremely easily led.
Does anyone here cruising around El Reg pages/staging posts see a singularity/parallel between what is recently discovered in TU Dresden and discussed on this thread and what you can read about happening elsewhere in another El Reg post commenting on another radically different matter ..... COSMIC Top Secret. Who's going to regulate the disinformation then?
Life in a Matrix Simulation and as a Series of Virtually Augmented Realities/Greater IntelAIgent GamesPlays with Sublime and Surreal and Supreme Alien Programming‽ .
Yeah, at first I was very excited but reading the article was a huge letdown. Basically under insanely specific circumstances a thread might be able to snoop another thread. So basically this works if you can already inject code into a process, just can't get at the thread you want, and the program is written to be vulnerable. So basically it's a sandbox break that exists in theory.
Good to know to avoid such a design for sandbox writers, big yawn otherwise.
My reading of it is much the same as yours. But by expanding the definition of a "Meltdown-style vulnerability" to include different threads of the same program, they can state that AMD chips are vulnerable to "Meltdown-style" attacks.
Other than some deeply cynical reasons, I can't think what the point of this is.
I suppose my question is around which of those "deeply cynical reasons" you're harbouring. The simplest and most charitable interpretation would be that these are academics and like all academics (and for that matter nearly all security researchers) they did some work and feel the need to publicise it to justify their next grant proposals. That's cynical but also just realistic; it's how academia works. Publishing negative results is good science; promoting them as something they're not is junk science and self-promotion. The greater fault lies with media outlets picking up the story and making something out of the nothing that it really is, and in particular calling it "Meltdown-style" which is like calling a wastebasket fire at a nuclear power company's offsite HQ a "meltdown-style heat excursion incident". Related in some obscure manner they surely are, but the connotation is all wrong.
Unfortunately that's the charitable interpretation. The more cynical would be that a competitor, most likely but not necessarily Intel, was ultimately behind both the research itself and the manner in which it has been presented to the public. Tracking down the sponsors of the research itself would be a simple matter of responsible reporting, so I hope our author already ruled out any second- or third-order involvement (e.g., sponsorship by an Intel Capital portfolio company, etc). Assuming that basic diligence was done, we're left to ask questions about undocumented influence among the researchers themselves as well as among those reporting on it in the popular press. That would be a good story for El Reg to pursue, assuming they haven't themselves been influenced in such a manner. Biting the hand that feeds, indeed.
I'm frankly inclined to the explanation less reliant on malice. Hyping research wins grants and hyping overhyped research results sells newspapers. There's nothing to see here but no one minds borderline libel if it puts food on the table. Prove me wrong.
"Prove me wrong."
That's a bit of a big ask, given that they've essentially redefined Meltdown as "a process can muck around with itself". Uh... and? Anybody who's ever debugged an errant memory access (like an oops uninitialised pointer) will know only too well what kinds of mischief this can result in.
Well, as the original "Meltdown" problem affected systems where both the kernel text and data spaces were present in the address space of all processes for both Windows and Linux, but protected by architectural storage protection, both the original version of "Meltdown", and this new definition would be affected by this.
The concept of including the kernel text and data spaces in each processes address space was done as a cheat to speed up system calls, as Intel processors and some others did not originally include different memory mapping registers for the various supervisor modes of the processor. PDP-11, VAX and even IBM 370 did not have this problem, and UNIX on these systems took full advantage of these features, as they had different sets of memory mapping registers for user and supervisor mode. This meant that whenever the system switched to supervisor mode during a system call, a different address space mapping just the kernel was automatically switched in, preventing the process from seeing anything other than it's own data.
This 'cheat' should have never existed, as better processor models existed long before Intel cam up with the memory model in 286, 386 and later processors.
But since Meltdown, as both Windows and Linux have addressed this by moving to a model where crossing the system call boundary involves changing the memory mapping registers to keep the kernel separate from use process address space (at the expense of slowing down system calls), this type of attack is now just relegated to protected threads in a single address space.
As IBM Power was mentioned, and I've not checked recently, IBM Power running AIX used to just map memory segment 0 into user processes (and have it protected so the process could not normally look at it), which was there to allow it to execute the code that performed 'short' system calls not needing access to the kernel data to be run without re-mapping the address space, and allow the code that would need access to be able to re-map the address space for 'long' system calls and the restore the processes own address space on return (at least this used to be how it worked on 32bit Power, this may be a dated view now all Power processors are 64 bit).
If a speculative execution vulnerability existed on IBM Power, then all a 'Meltdown' type problem would allow on AIX on Power would be to see the machine code that exists in segment 0, which is available elsewhere on the system anyway. But it may have existed in Linux on Power, which effectively includes the Power Hypervisor, so IBM did produce new firmware (which includes the Hypervisor) to address this, not that the Hypervisor was vulnerable as you can't execute anything on it.
I guess it's possible that one thread of a program is bad and it can spy on another thread. The closest I can think of is something like javascript(in a browser with multiple windows or tabs), php, python, etc, where your code could be interpreted in a shared environment with others and make it possible for you to spy on the other threads from the same interpreter.
Or maybe a multithreaded program like apache, where it's possible for apache's mod_php etc execute your malware and use it to spy on the other apache threads - maybe,
Am just guessing where this may be possible, not saying this is how it is.
Of course the article already states that the Firefox's javascript engine seems safe against this but does not mention chrome or anything else.
I guess it's possible that one thread of a program is bad and it can spy on another thread. The closest I can think of is something like javascript(in a browser with multiple windows or tabs), php, python, etc, where your code could be interpreted in a shared environment with others and make it possible for you to spy on the other threads from the same interpreter. ..... BOFH in Training
Considering that as an Almighty Feature has Resultant COSMIC Futures in FuturistICQ AIdVentures a Prized Asset to Savour and Manoeuvre/Exercise and Mentor/Monitor and Provide with Heavenly Succour/Enthusiastic Energetic Remote Virtually Realised Support. ....... which one would find it impossible to dismiss and miss is easily correctly mistaken for Almighty Help and/or an Alien Intervention in Earthly Capital Markets for Interest to Generate the Provision and Funding of/for Future Supply.
Such makes it prohibitively expensive to try and own but incredibly lucrative to seed with extremely speculative venture capital funding of/for Interesting Future Suppliers.
Author of the paper is here vvv:
Thanks a lot for your inputs guys, they are appreciated. May be few things I want to clarify here:
- we didn't claim it a vulnerability, but a hardware flaw which leads to a certain predictable change in the uarch state;
- according to spectre/meltdown taxonomy (https://pure.tugraz.at/ws/portalfiles/portal/28987078/transient_attacks.pdf) this behavior falls under meltdown type; We also say that classical meltdown doesnt work bc the certain design in AMD cpus. At current point, ofc classifying it under the meltdown class is very academical, and doesnt lead (and never supposed to be) to a new "AMD MELTDOWN" boom. I admit, that classifying it under meltdown class brought too much attention, and might feel overhyped, so all your concerns are well understood.
- Same address space: We provide only synthetic scenario, where such a flaw in hardware may lead to unnecessary side effects and can be exploited for sandboxes only ( no cross address space).
- cynical reasons: We tried to push the paper to EuroSec 2021 Workshop, but got a weak reject due to lack of full exploit, so I tried to write a paper in a way it will be sold there, thats the only driver for writing this paper. No vendors or any other parties were behind funding or whatever. I did this research in my "free time" as a research assistant in uni. I spend some time on it and I also believe that these are interesting results for sure. Moreover, AMD admitted the presence of the problem and agreed that it MIGHT have effect in real systems.
Actually I personally think that it is a laudatory paper for AMD, bc we show that meltdown (at least how we understand meltdown today) does not and will not work on AMD cpus.
How serious is it?
Conceptually, it matters. Practically ... it shows potential ~ that's all. These EPYC chips are not perfectly locked down either...
Practically, unless you can figure out how to get one thread to mess with another that's not part of the same program, that's not got the same ownership, that's not running on the same core and controlled by the same virtual-machine...
This is not the same kind of exposure Intel have got at all. This is about one thousandth as bad. This (as far as I can see) is perfectly and exactly in line with what AMD have said many times about this stuff. We're not as prone as Intel but we're not sure we're completely bullet-proof either.
"How serious is it?"
If Meltdown was compound fractures of both femurs, a crushed pelvis, and pulverised guts, this is someone giving you a noogie. If Meltdown was the Pacific Ocean, this is a droplet of mist from an atomiser. If Meltdown was an actual nuclear reactor meltdown, this is the afterglow of an extinguished match.
In other words, it's nothing. Even the author has agreed that it's not a vulnerability at all. There is no exploit, none is even possible because the only thing you could do with it is something you could already do anyway. Quite honestly, the best analogue I can suggest is http://www.m1racles.com/ which if you really think about it is actually more significant than this despite the author's acceptance that it's so trivially unimportant as to deserve a parody report. But they are both implementation defects that are of academic interest and possibly of interest to microarchitectural engineers but pose no threat whatsoever to real-world software.
"This is about one thousandth as bad."
Much less. This is not bad at all; it's harmless.
"We're not as prone as Intel but we're not sure we're completely bullet-proof either."
That distorts the truth. AMD's cores are not vulnerable to Meltdown. Intel's are. Period. There are plenty of real bugs in AMD's cores that are serious, and probably some that haven't yet been found. With Intel falling 2 generations behind AMD on performance and getting their asses handed to them by the market it's not surprising that researchers are taking a closer look here. That's good. No one is sure they're bulletproof in terms of microarchitectural side channels, in general, and it's quite possible they'll find something as bad in AMD's cores as Meltdown is in Intel's. But this is nothing, and it's not evidence that AMD are somehow not sure their cores aren't vulnerable to Meltdown. That's known, it's been proven, and the fact that other researchers have now had yet another go-round and found nothing should put it to bed entirely. If you want to find serious side channel bugs in AMD cores, look elsewhere.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
