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

221–230 of 378 posts

Re: Zenbleed

#221

Post by anarazel »

Tuna-Fish wrote: post #84
ye-olde-sysrq wrote: post #75

Earlier quoted context omitted.

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)

You are likely frequently running untrusted workloads. As javascript in a browser. I don't know about this one, but at least meltdown was fully exploitable from js. But yes, you are fine, 5950x is Zen3.

I wish Firefox would use PR_SCHED_CORE to reduce the likelihood of such leakage...

Re: Zenbleed

#222

Post by tracker1 »

darkwater wrote: post #148
javajosh wrote: post #95

Earlier quoted context omitted.

I mean, the PS5 is running a Zen 2 processor [0] so I would assume it's vulnerable. In general I would assume that AAA games are safe. Websites and smaller games made by malefactors will be the issue. (Note that AAA game makers have little interest in antagonizing the audience, OTOH they also will push limits to install anti-cheat mechanisms. On balance I'd trust them.) 0 - https://blog.playstation.com/2020/03/18/unv…

I think the interesting point here might be one could be able to extract some secret from memory of a PS5, like to break some kind of encryption

Interresting, could well be a path to jailbreaking the PS5... although, not sure if that has or hasn't already happened. For XBox Series, you can just use dev mode in the first place.

Re: Zenbleed

#223

Post by johnp_ »

blinkingled wrote: post #219

On my Zen2 / Renoir based system the PoC exploit continues to work albeit slowly even after updating the microcode (linked from TFA) that has the fix for this issue. The wrmsr stops it fully in its track. Edit: just realized it must have been that the initramfs image is not updated with the manually updated firmware in /lib/firmware. Edit2: Updated the initramfs and even if the benchmark.sh fails, ./zenbleed -v2 stil…

linux-firmware does not carry any microcode update for Renoir (yet). Or what do you mean by "TFA"?

The fixed Renoir microcode should have revision >= 0x0860010b as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

Re: Zenbleed

#224

Post by saagarjha »

MuffinFlavored wrote: post #218
phendrenad2 wrote: post #101

Earlier quoted context omitted.

The problem is, VMs aren't really "Virtual Machines" anymore. You're not parsing opcodes in a big switch statement, you're running instructions on the actual CPU, with a few hardware flags that the CPU says will guarantee no data or instruction overlap. It promises! But that's a hard promise to make in reality.

> you're running instructions on the actual CPU Just how many times is the average operating system workload (with or without a virtual machine also running a second average operating system workload) context switching a second? Like... unless I'm wrong... the kernel is the main process, and then it slices up processes/threads, and each time those run, they have their own EAX/EBX/ECX/ESP/EBP/EIP/etc. (I know it's RAX…

Usually a few hundred to a few thousand times a second.

Re: Zenbleed

#225

Post by saagarjha »

c7DJTLrn wrote: post #71
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.

That is not true in this case. It's just a CPU bug; not even a side channel.

Re: Zenbleed

#226

Post by saagarjha »

0cf8612b2e1e wrote: post #113
cmrdporcupine wrote: post #70

Earlier quoted context omitted.

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…

If you pin the VM to a different core/CPU, would that do anything to mitigate? Or are the OS affinity guarantees not that strong?

In this case, it would avoid the exploit, because it requires a shared register file.

Re: Zenbleed

#227

Post by FirmwareBurner »

kmeisthax wrote: post #215
FirmwareBurner wrote: post #156

Earlier quoted context omitted.

What valuable secrets do people have on their PS5/Xbox? You also need a way to deploy the malicious payload on those platforms which, due to their closed nature, is very difficult to do.

The valuable secret here would be the keys that let you decrypt and copy games. The threat models of locked-down platforms are incredibly strange.

That's a good point but I can't believe that every console doesn't have it's own unique set of keys so that if you compromise one before SW patches land, it won't be much use in the ecosystem.

Re: Zenbleed

#228

Post by kzrdude »

tremon wrote: post #92
naikrovek wrote: post #91

Earlier quoted context omitted.

no. microcode changes are provided to the CPU at boot time and are only valid early in the boot process. the machine UEFI/BIOS must apply them.

Linux can (and does) apply microcode patches during kernel boot.

for example use journalctl -k -g microcode to see log messages related to this: (intel cpu, so revision does not relate to anything AMD)

> microcode: microcode updated early to revision 0xa6, date = 2022-06-28

Re: Zenbleed

#229

Post by hedgehog »

Tuna-Fish wrote: post #80
cmrdporcupine wrote: post #70

Earlier quoted context omitted.

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.

In certain cases isolation and simplicity overlap, I suspect for example that the dangers of SMT implementation complexity are part of why Apple didn't implement it for their respective CPUs. Likely we'll see this elsewhere too, for example Amazon may not ever push to have SMT in their Graviton chips (the early generations are off the shelf cores from ARM where they didn't have a readily available choice).

Re: Zenbleed

#230

Post by toast0 »

MuffinFlavored wrote: post #218
phendrenad2 wrote: post #101

Earlier quoted context omitted.

The problem is, VMs aren't really "Virtual Machines" anymore. You're not parsing opcodes in a big switch statement, you're running instructions on the actual CPU, with a few hardware flags that the CPU says will guarantee no data or instruction overlap. It promises! But that's a hard promise to make in reality.

> you're running instructions on the actual CPU Just how many times is the average operating system workload (with or without a virtual machine also running a second average operating system workload) context switching a second? Like... unless I'm wrong... the kernel is the main process, and then it slices up processes/threads, and each time those run, they have their own EAX/EBX/ECX/ESP/EBP/EIP/etc. (I know it's RAX…

> How many cycles is a thread/process given before it context switches to the next one?

Depends on a lot of things. If it's a compute heavy task, and there's no I/O interrupts, the task gets one "timeslice", timeslices vary, but typical times are somewhere in the neighborhood of 1 ms to 100 ms. If it's an I/O heavy task, chances are the task returns from a syscall with new data to read (or because a write finished), does a little bit of work, then does another syscall with I/O. Lots of context switches in network heavy code (io_uring seems promising).

> How is it managing all of the pushfd/popfd, etc. between them?

The basic plan is when the kernel takes an interrupt (or gets a syscall, which is an interrupt on some systems and other mechanisms on others), the kernel (or the cpu) loads the kernel stack pointer for the current thread, then it pushes all the (relevant) cpu registers onto the stack, then the kernel business it taken care of, the scheduler decides which userspace thread to return to (which might be the same one that was interrupted or not), the destination thread's kernel stack is switched to, registers are popped, then the thread's userspace stack is switched to, then userspace execution resumes.

Post reply on HN