12 ms·
This is a wild guess, but could this feature be disabled in an attempt at preventing some publicly undisclosed hardware vulnerability?
by shantara 2y ago
This is a wild guess, but could this feature be disabled in an attempt at preventing some publicly undisclosed hardware vulnerability?
- throw_away_x1y2 2y agoBingo. I can't say more. :(
- pdimitar 2y agoHave we learned nothing from Spectre and Meltdown?... :(
- aseipp 2y agoThis might come as a shock, but I can assure you that the designing high end microprocessors have probably forgotten more about these topics than most of the people here have ever known.
- pdimitar 2y agoHuh?
- gpderetta 2y agoComplex systems are complex?
- pdimitar 2y agoSadly you're right. And obviously we're not about to give up on high IPC. I get it and I'm not judging -- it's just a bit saddening.
- StressedDev 2y agoA lot has been learned. Unfortunately, people still make mistakes and hardware will continue to have security vulnerabilities.
- sweetjuly 2y agoI imagine this is more of a functional issue. i.e., the loop buffer caused corruption of the instruction stream under some weird specific circumstances. Spectre and Meltdown are not functional issues but rather just side channel issues. This should be fun, however, for someone with enough time to chase down and try and find the bug. Depending on the consequences of the bug and the conditions under which it hits, maybe you could even write an exploit (either going from JavaScript to the browser or from user mode to the kernel) with it :) Though, I strongly suspect that reverse engineering and weaponizing the bug without any insider knowledge will be exceedingly difficult. And, anyways, there's also a decent chance this issue just leads to a hang/livelock/MCE which would make it pointless to exploit.
- rincebrain 2y agoThe problem is that we're more or less stuck with this class of problem unless we end up with something that looks like a Xeon Phi without shared resources and run calculations on many, many truly independent cores, or we accept that the worst and best case performance cases are identical (which I don't foresee anyone really agreeing to). Or, framed differently, if Intel or AMD announced a new gamer CPU tomorrow that was 3x faster in most games but utterly unsafe against all Meltdown/Spectre-class vulns, how fast do you think they'd sell out?
- thechao 2y agoLarabee was fun to program, but I think it'd have an even worse time hardening memory sideband effects: the barrel processor (which was necessary to have anything like reasonable performance) was humorously easy to use for cross-process exfiltration. Like... it was so easy, we actually used it as an IPC mechanism.
- wheybags 2y ago> it was so easy, we actually used it as an IPC mechanism. Can you elaborate on that? It sounds interesting
- thechao 2y agoNow you’re asking me technical details from more than a decade ago. My recollection is that you could map one of the caches between cores — there were uncached-write-through instructions. By reverse engineering the cache’s hash, you could write to a specific cache-line; the uc-write would push it up into the correct line and the “other core” could snoop that line from its side with a lazy read-and-clear. The whole thing was janky-AF, but way the hell faster than sending a message around the ring. (My recollection was that the three interlocking rings could make the longest-range message take hundreds of cycles.)
- rincebrain 2y agoSure, absolutely, there's large numbers of additional classes of side effects you would need to harden against if you wanted to eliminate everything, I was mostly thinking specifically of something with an enormous number of cores without the 4-way SMT as a high-level description. I was always morbidly curious about programming those, but never to the point of actually buying one, and I always had more things to do in the day than time in past life when we had a few of the cards in my office.
- Am4TIfIsER0ppos 2y ago[flagged]
- shepherdjerred 2y agoThis seems unnecessarily cynical. Are you saying Intel/AMD are intentionally crippling CPUs?
- bobmcnamara 2y agoI'm not saying Intel intentionally limited CPUs, just that they have intentionally limited a lot of things and lied about it in the past. https://www.ftc.gov/news-events/news/press-releases/2010/08/ftc-settles-charges-anticompetitive-conduct-against-intel https://www.ftc.gov/news-events/news/press-releases/2010/08/...
- Am4TIfIsER0ppos 2y agoIntentionally adding bugs? No. Intentionally making them slower with microcode and other software updates? Yes.
- tedunangst 2y agoI was told the lesson is to avoid Intel and only buy AMD because they don't make mistakes.
- UberFly 2y agoNo one said to buy AMD because they don't make mistakes. AMD just currently makes a better product overall.
- Dylan16807 2y agoI do not think you are accurately recounting what people said.
- AlexeyBelov 2y agoWas told by whom?
- PittleyDunkin 2y agoI'm still not convinced most of the computers in my home need to care about leaking data this way. I'm open to being persuaded, though.
- pdimitar 2y agoI am not convinced either but I am willing to bet some software is adversarial and will try to exfiltrate data. F.ex. many people look suspiciously at Zoom and Chrome. So as long as stuff is not perfectly isolated from each other then there's always a room for a bad actor to snoop on stuff.
- api 2y agoFor most of these vulnerabilities the risk is low, but keep in mind that your web browser runs random untrusted code from all over the Internet in a VM with a JIT compiler. This means you can't rule out the possibility that someone will figure out a way to exploit this over the web reliably, which would be catastrophic. "Attacks only get better."
- PittleyDunkin 2y agoRight, but there's presumably little data to worry about exfiltrating from, say, my xbox. Even stuff like billing info doesn't need to be stored locally.
- RobotToaster 2y agoWe should have learnt from the fdiv bug[0] that processor manufacturers need to be mandated to recall faulty hardware. [0] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
- nine_k 2y agoIt depends on the severity of the problem, and the impact on the customers already using these systems. It may be more economical for the customer to apply a patch and lose a few percent of peak performance than to put thousands of boxes offline and schedule personnel to swap CPUs. This is to say nothing of the hassle of bringing your new laptop to a service center, and taking a replacement, or waiting if your exact configuration is unavailable at the moment.
- bell-cot 2y agoThe Article more-or-less speculates that: > Zen 4 is AMD's first attempt at putting a loop buffer into a high performance CPU. Validation is always difficult, especially when implementing a feature for the first time. It's not crazy to imagine that AMD internally discovered a bug that no one else hit, and decided to turn off the loop buffer out of an abundance of caution. I can't think of any other reason AMD would mess with Zen 4's frontend this far into the core's lifecycle.
- bhouston 2y agoYeah, my first thoughts too.
- BartjeD 2y agoQuitely disabling it is also a big risk. Because you're signalling that in all probablity you were aware of the severity of the issue; Enough so that you took steps to patch it. If you don't disclose the vulnerability then affected parties cannot start taking countermeasures, except out of sheer paranoia. Disclosing a vulnerability is a way shift liability onto the end user. You didn't update? Then don't complain. Only rarely do disclosures lead to product liability. I don't remember this (liability) happening with Meltdown and Spectre either. So wouldn't assume this is AMD being secretive.
- deleted 2y ago[deleted]
- wtallis 2y agoPlease don't post duplicate comments like this. Your first comment (https://news.ycombinator.com/item?id=42287118 https://news.ycombinator.com/item?id=42287118) was fine but spamming a thread with copy-and-pasted comments just hurts the signal to noise ratio.
- alexnewman 2y agoIm confused would you be ok if he's addressing the same point in the forum with a slightly different sentence?
- wtallis 2y agoAny threaded discussion carries the risk of different subthreads ending up in the same place. The simplest solution is to just not post twice, and trust that the reader can read the rest of the thread; HN threads usually don't get long enough for good comments to get too buried, and not duplicating comments helps avoid that problem. If there's something slightly different, it may be worth linking to another comment in a different subthread and adding a few sentences to cover the differences. Copying a whole comment is never a good answer, and re-wording it to obscure the fact that it's not saying anything new is also bad. New comments should have something new to say.
- baq 2y agoIndeed, it might be the case that there’s more than that disabled, since numbers are somewhat surprising: > Still, the Cyberpunk 2077 data bothers me. Performance counters also indicate higher average IPC with the loop buffer enabled when the game is running on the VCache die. Specifically, it averages 1.25 IPC with the loop buffer on, and 1.07 IPC with the loop buffer disabled. And, there is a tiny performance dip on the new BIOS. Smells of microcode mitigations if you ask me, but naturally let’s wait for the CVE.
- hinkley 2y agoOr another logic bug. We haven’t had a really juicy one in a while.