6 ms·
AMD's Zen 3 CPUs Are Susceptible to Spectre-Like Vulnerability
- makomk 6y agoThe underlying AMD paper made the front page of HN a few days ago, though without much discussion: https://news.ycombinator.com/item?id=26645903 https://news.ycombinator.com/item?id=26645903 It's an interesting vulnerability but of limited impact, since of course every fast modern CPU is affected by Spectre anyway. The main consequence seems to be that, at least in theory, this has to be disabled in order for certain Spectre mitigations to work correctly. I don't think anyone's found a practical attack using this yet.
- hpcjoe 6y agoThe operative phrase is "yet". Better safe than sorry. I've not read the paper yet, and I am curious on the performance impact. I don't mind trading some performance for better security. Because when exploits are found in the wild, its too late.
- mlyle 6y agoThe thing is, this can be disabled A) per thread, and B) can't leak from other processes (it's flushed on each context switch). So really, we want certain processes with software based sandboxing -- e.g. Javascript interpreters-- to turn this off.
- alanfranz 6y agoWasn’t a spectre paper published some days ago, and extensively discussed on hn? All cpus can be affected by spectre. Including arm, mips, etc. Unless we totally disable speculative execution/branch prediction, which will impact performance. A lot. EDIT: it wasn't a paper per-se, but the Google PoC: https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
- mhh__ 6y agoSpectre-like is the key thing here. They've introduced a new mechanism accessible presumably by a similar side channel (haven't read the paper yet)
- alanfranz 6y agoSpectre is a class of bugs right now. The "classical" spectre relies on branch prediction, here we have another kind of prediction... but it's not that different, IMHO.
- mhh__ 6y agoThese vulnerabilities will probably be around as long as we have this breed of processors, at the very least. I can't see an obvious way to hide the processors internal state at this level while also maintaining a weak enough structure to allow performance. Maybe there's ideas cooking inside the chip companies but so far I haven't seen anything public
- wffurr 6y agoARMv9 hardware memory segmentation seems promising: https://www.anandtech.com/show/16584/arm-announces-armv9-architecture/2 https://www.anandtech.com/show/16584/arm-announces-armv9-arc...
- ethbr0 6y agoDoesn't that preclude shared memory?
- emayljames 6y agoThis processor, that constantly shifts things around, is currently unhackable: https://m.hexus.net/tech/news/cpu/147532-unhackable-morpheus-computer-chip-lives-billing/ https://m.hexus.net/tech/news/cpu/147532-unhackable-morpheus...
- willvarfar 6y agoKudos to AMD for looking for, finding and then publicizing this themselves. I wonder if they have red teams trying to break things when they are still in the design stage? And of course another plus is that we don’t have some vapid detail-light brand-heavy vulnerabilities-need-a-name website popping up too!
- tim-- 6y agoI thought the whole AMD team was the red team! /s
- parsimo2010 6y ago> another plus is that we don’t have some vapid detail-light brand-heavy vulnerabilities-need-a-name website AMD disclosing this vulnerability in a way in which they control the message is a big win from their corporate perspective. I'll bet their reputation/stock price takes less of a hit this way than if a security researcher discovered the vulnerability and hyped up the impact. This way AMD gets to downplay this while seeming reasonable and say up front, "most people don't need to be worried we're not aware of anyone using this attack in the wild." This was also true when Spectre was discovered, but since Intel weren't the ones that discovered the vulnerability, the response from Intel that nobody was using it felt like they were doing damage control rather than a sincere risk assessment. Everyone needs to mitigate every vulnerability regardless of whether an attack is being used at the moment. It will definitely be used in an attack in the future if nobody fixes it. AMD saying this is just as much damage control as when Intel did it, but it feels different.
- Daho0n 6y agoYou think Intel would publish if they had found spectre themselves? Edit: Okay, this reads like a snarky question ala "as if Intel would have done that!" but that wasn't what I were aiming for. Sorry about that.
- woofie11 6y agoI think classic Intel would. Intel's major cash cow and selling point was trust and brand. Until recently, I bought Intel processors and motherboards through good and bad because Intel had brand credibility. AMD sometimes gave better price-performance, but no one beat Intel for reliability and trust. Intel processors, chipsets, wifi, etc. were stable, had quality drivers, and QC was excellent. I knew the stuff would work. I don't care about a 30% difference in performance nearly as much as that. Historically, Intel was very good about publishing processor manuals, and bug lists. They weren't always perfect about fixing them, mind you, but they weren't bad either. Recall the FDIV bug. They took a lot of flack for that, but ultimately, they agreed to replace all affected processors. Or read e.g. an Intel 80486 manual and errata. Intel seems to be imploding right now, and I don't know that they would publish something like this today, but that's a pretty recent phenomenon -- past five years or so. I just bought my first AMD desktop (with ECC!), but I'm still kind of hoping Intel will go back to the old ways -- transparent, reliable, documented, stable, and trustworthy. I'd rather get that, even if I need to pay double or lose a little bit of performance. Those allowed Intel to sell high-margin products. I'm not sure if the market would sustain that today. Perhaps the market for high-margin products has imploded. Right now, cloud infrastructure seems to rely on massive numbers of less reliable systems, rather than super-reliable servers as we had even a decade ago. Scientific computing has moved in a similar direction. No one makes serious business laptops/desktops anymore like classic IBM ThinkPads (which ran around $10k in today's dollars) or Sun/SGI/HP/etc. workstations for that matter. Or it might be that Intel drove the market in that direction. I can't quite tell. Or it might be that AMD is taking Intel's former niche. Again, with AMD, my desktop finally has ECC again. That's something I haven't had for many years. What I'd really like is a reliable laptop which could self-monitor. Memory has ECC. SSD has RAID. Every wire is monitored for errors, and if there's an issue somewhere, it can be pinpointed to the user. USB devices can't crash my computer. If any IC is unreliable, I'm immediately let know about what failed. If a hard drive has a bad cable, I'm told which cable is bad. If a fan is failing, I know. All voltages are monitored. If a heatsink falls off, the system shuts itself down with no damage and logs the event. Computations is error-correcting. Etc. The hardware Just Works, and if something breaks, I can fix it proactively rather than reactively when I lose my data. Think of the systems NASA used in the space shuttle. It wouldn't add much to the cost; most of this is just NREs. The amount of actual silicon needed would be pretty small.
- BlueTemplar 6y agoAny ideas about Ryzen CPU susceptibility to built-in backdoors ? https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
- throw0101a 6y agoEverything is susceptible to backdoors depending on your level of paranoia. You can have an open source architecture, like RISC-V, and yet the people at the fab can insert backdoors into the silicon. Building trusted hardware is an area of active research: * https://spectrum.ieee.org/semiconductors/design/stopping-hardware-trojans-in-their-tracks https://spectrum.ieee.org/semiconductors/design/stopping-har... Then you have to worry about trusting software. Even if you compile it from scratch, the compiler itself can be a threat (as outlined by Thompson1984): * https://www.schneier.com/blog/archives/2006/01/countering_trus.html https://www.schneier.com/blog/archives/2006/01/countering_tr... * PDF: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- BlueTemplar 6y agoOf course. To be more specific, I'm concerned about widespread compromise by NSA of computers in European companies with the goal of industrial espionage. (Like the way that Intel's Management Engine can potentially be this kind of threat.)
- opencl 6y agoIf you're concerned about Intel's ME, AMD's PSP is basically the same thing.
- Causality1 6y agoConsumers who work with software that employs sandboxing and are alarmed about PSF have the choice to disable the PSF functionality Thank goodness. That's a much better way of handling it than the "sky is falling" response to Spectre and Meltdown that saw some people receive 20% performance drops via silent Windows Updates, despite neither of them being actively exploited in the wild.
- JediPig 6y agoI seen the benchmarks with it on and off.... and.. sometimes you cant tell its off, all with the margin of error. More than likely, they are just going to perm turn it off. There will be no difference in performance.
- Proven 6y agohaha.... wasn't the absence of it a major selling point often highlighted on HN? i want my money back!
- Fire-Dragon-DoL 6y agoAre we going to see cpu performance decrease in amd too?
- ByTheBook 6y agoPhoronix did a benchmark on Linux, and states that the performance impact was less than a half percent: https://www.phoronix.com/scan.php?page=article&item=amd-zen3-psf&num=1 https://www.phoronix.com/scan.php?page=article&item=amd-zen3...
- Fire-Dragon-DoL 6y agoOh that's cool, I'm not looking forward another downgrade like the Spectre one