Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zenbleed

lock.cmpxchg8b.com

Post reply on HN
Print view View original

71–80 of 378 posts

Re: Zenbleed

#71

Post by c7DJTLrn »

0xbadcafebee wrote: post #44

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…

Running untrusted code whether in a sandbox, container, or VM, has not been safe since at least Rowhammer, maybe before. I believe a lot of these exploits are down to software and hardware people not talking. Software people make assumptions about the isolation guarantees, hardware people don't speak up when said assumptions are made.

Re: Zenbleed

#72

Post by rincebrain »

tremon wrote: post #49
lopkeny12ko wrote: post #4

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…

Do they mean "only confirmed on Zen2", or is the problem definitely confined to only this architecture? Is it likely that this same technique (or similar) also works on earlier (Zen/Zen+) or later (Zen3) cores, but they just haven't been able to demonstrate it yet?

At least the stock exploit code he provided said "nope I can't get shit to leak" on my 5900X.

Re: Zenbleed

#73

Post by justinclift »

lopkeny12ko wrote: post #4

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…

Whew, my 5600X looks like it avoided this one too. :)

Re: Zenbleed

#74

Post by artisanspam »

Why does disabling SMT not fully prevent this? I don't know the details of Zen 2 architecture, but register files are usually implemented as SRAM on the CPU-die itself. So unless the core is running SMT, I don't understand how another thread could be accessing the register file to write a secret.

Re: Zenbleed

#75

Post by ye-olde-sysrq »

lopkeny12ko wrote: post #4

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…

So are Ryzen 5000's without Radeon not vulnerable? I guess said processors are zen 3?

I have an "AMD Ryzen 9 5950x Desktop Processor" which appears to be Zen 3. I think I'm good?

(Not that I'm running untrusted workloads, but yknow, fortune favors the prepared)

Re: Zenbleed

#76

Post by formerly_proven »

ls612 wrote: post #36
Night_Thastus wrote: post #7

Earlier quoted context omitted.

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.

My new computer takes a while to POST (z690 with ddr5 smh) so it’s basically been continuously either on or in sleep since I built it 18 months ago and I’ve had an unexpected shutdown due to power loss once in that time according to the Event log. I think the risk of losing power while flashing the bios is very small in real life unless you are stuck in a place with third world electricity infrastructure.

If POST takes a long time it’s often memory training, backing off on the timings just slightly might make it go a lot quicker. Bios updates also often twiddle knobs in this area.

Re: Zenbleed

#77

Post by wbl »

artisanspam wrote: post #74

Why does disabling SMT not fully prevent this? I don't know the details of Zen 2 architecture, but register files are usually implemented as SRAM on the CPU-die itself. So unless the core is running SMT, I don't understand how another thread could be accessing the register file to write a secret.

Because the context switch only affects architectural state not microarchitectural state.

Re: Zenbleed

#78

Post by c7DJTLrn »

cmrdporcupine wrote: post #70
0xbadcafebee wrote: post #44

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…

We demanded more performance and we got what we demanded. I doubt manufacturers are going to walk back on branch prediction no matter how flawed it is. They'll add some more mitigations and features which will be broken-on-arrival.

Re: Zenbleed

#79

Post by zamadatix »

0xbadcafebee wrote: post #44

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 case of the VM won't registers be wiped when entering/exiting the VM?

Re: Zenbleed

#80

Post by Tuna-Fish »

cmrdporcupine wrote: post #70
0xbadcafebee wrote: post #44

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…

> At what point does the complexity of CPU architectures become so difficult to reason about that we just accept the performance penalty of keeping it simpler?

Never for branch prediction. It just gets you too much performance. If it becomes too much of a problem, the solution is greater isolation of workloads.

Post reply on HN