111–120 of 378 posts
I don't understand how a microcode update could fix this. I assume microcode is used for slow operations like triginometric functions, and doesn't affect how registers are allocated or renamed. Or does the update simply disables some optimizations using "chicken bits"? And by the way, is there a list of such bits?
This is super cool. This exploit will be one of the canonical examples that just running something in a VM does not mean it's safe. We've always known about VM breakout, but this is a no-breakout massive exploit that is simple to execute and gives big payoffs. Remember: just because this one bug gets fixed in microcode doesn't mean there's not another one of these waiting to be discovered. Many (most?) 0-days are kno…
In the end, I'm thinking most of these are related to branch prediction? It strikes me that it's either that branch prediction is so inherently complex enough it's always going to be vulnerable to this and/or it just so defies the way most of us intuitively think about code paths / instruction execution that it's hard to conceive of the edge cases until too late? At what point does the complexity of CPU architectures…
Earlier quoted context omitted.
does it require physical access to the machine?
I was able to reproduce the vulnerability using javascript on a webpage. Therefore, no.
You've even been quoted elsewhere in this thread about this topic.
Earlier quoted context omitted.
The problem is the freed entries in the register file. A VM can, at least, use this bug to read registers from a non-VM thread running on the adjacent SMT/HT of a single physical core. I suspect a VM could also read registers from other processes scheduled on the same SMT/HT.
Are people running multiple untrusted VMs without turning SMT off? Even letting them share caches seems like asking for trouble.
No details on the performance impact of the microcode update. Presumably it disables speculative execution of vzeroupper?
Or adds a guard. They mention perf issues for the workaround but they're notably absent from the microcode commentary. I wonder what this is going to do to the new AMD hardware AWS is trying to roll out, which is supposed to be a substantial performance bump over the previous generation.
> AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it. Yes, I love flashing BIOS... edit nvm, Microcode can get updated via system updates.
To be fair, flashing the bios isn't nearly as bad on most modern systems. Put the file on a USB drive, plug it in, restart and go into the bios, look for the flashing utility, select the file, done. As long as the machine is on a UPS in case of disaster, everything's accounted for.
Relevant snippet: This technique is CVE-2023-20593 and it works on all Zen 2 class processors, which includes at least the following products: AMD Ryzen 3000 Series Processors AMD Ryzen PRO 3000 Series Processors AMD Ryzen Threadripper 3000 Series Processors AMD Ryzen 4000 Series Processors with Radeon Graphics AMD Ryzen PRO 4000 Series Processors AMD Ryzen 5000 Series Processors with Radeon Graphics AMD Ryzen 7020 S…
The site is getting hugged to death. https://web.archive.org/web/20230724143835/https://lock.cmpx...
It is a simple static HTML page, how is it possible in 2023 a static site could be hugged to death. In most cases HN traffic barely hits 100 page view per second.
No details on the performance impact of the microcode update. Presumably it disables speculative execution of vzeroupper?
Or adds a guard. They mention perf issues for the workaround but they're notably absent from the microcode commentary. I wonder what this is going to do to the new AMD hardware AWS is trying to roll out, which is supposed to be a substantial performance bump over the previous generation.