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

281–290 of 378 posts

Re: Zenbleed

#281

Post by insanitybit »

Kwpolska wrote: post #212
Bluecobra wrote: post #83

Earlier quoted context omitted.

Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap these VMs to it's own dedicated hypervisor it always fell on deaf ears. Jokes on them I guess.

I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.

Yes but the Firecracker VMs are pinned to specific cores. So no two tenants never share a CPU core. Other than Rowhammer, has there been a hardware vulnerability of this nature that has worked x-core? I don't recall.

Still, I think that if your company is handling user data it's worth seriously considering dedicated instances for any service that encounters plaintext user information.

Re: Zenbleed

#282

Post by insanitybit »

ransackdev wrote: post #129
yakubin wrote: post #108

Earlier quoted context omitted.

FWIW, enabling gzip/zstd compression in your HTTP server could help.

A single core machine already overloaded is going to get even worse introducing the cpu overhead of gzipping response bodies (assuming it’s cpu bound and not IO bound) Cache control headers will help with return traffic More cpu cores If using nginx ensure sendfile is enabled and workers are set to auto or tuned for your setup Check ulimit file handle limits Offload static assets to cdn Since it’s a static html site,…

> A single core machine already overloaded is going to get even worse introducing the cpu overhead of gzipping response bodies (assuming it’s cpu bound and not IO bound)

Unless your CPU is burning due to additional system calls being made.

Re: Zenbleed

#283

Post by [deleted] »

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…

[deleted]

Re: Zenbleed

#284

Post by naikrovek »

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.

oh.

every time I think I'm right, I'm wrong, and every time I think I'm wrong, I'm right.

except here. I'm always wrong, here.

Re: Zenbleed

#285

Post by segfaultbuserr »

yencabulator wrote: post #214
Kwpolska wrote: post #212

Earlier quoted context omitted.

I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.

You can pay AWS a premium to make sure you're the only tenant on the physical machine. You can also split your own stuff into multiple tenants, and keep those separate too.

Eric Brandwine (VP/DE @ AWS) said publicly in 2019 that EC2 had never scheduled different tenants on the same physical core at the same time, even before we learned about these kinds of side-channel attacks.

https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s

Re: Zenbleed

#286

Post by yencabulator »

segfaultbuserr wrote: post #285
yencabulator wrote: post #214

Earlier quoted context omitted.

You can pay AWS a premium to make sure you're the only tenant on the physical machine. You can also split your own stuff into multiple tenants, and keep those separate too.

Eric Brandwine (VP/DE @ AWS) said publicly in 2019 that EC2 had never scheduled different tenants on the same physical core at the same time, even before we learned about these kinds of side-channel attacks. https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s

Yes (lowest vCPU seems to be 2 everywhere), and that protects against this attack. However, this thread was talking about airgapping hosts, which is needed for the general threat of VM escapes.

Re: Zenbleed

#287

Post by marmakoide »

jahsome wrote: post #125
laverya wrote: post #64

Earlier quoted context omitted.

The patch for this exploit is to load AMD's updated microcode.

I'm not sure five year olds know what microcode is. I'm 35, been in tech nearly 20 years and don't recall having heard that specific term before today.

I can explain to a 35 years old in tech.

A modern generalist CPU is made of many smaller, simpler, specialized CPUs : there's a whole orchestra inside.

Amongst those smaller CPUs, there's a master : it'll see to decoding of instruction, sending jobs to the various CPU units, and fetching the results of said jobs. That master is running a program, executing ... microcode ! And of course, if there is a program, there are bugs. CPUs have bugs since CPUs were invented.

Microcode itself was present in early CPUs, (say, the Z80), but hardcoded. Nowadays, microcode can be uploaded to a CPU to fix bugs.

Re: Zenbleed

#288

Post by [deleted] »

vladvasiliu wrote: post #136
gabereiser wrote: post #98

Earlier quoted context omitted.

This. Not everyone is as quick as say Arch or Fedora in updating/patching. Please reach out to your maintainers of the distro you use.

Even Arch seems out of date as of 24 jul 2023 17:55 UTC. The latest amd firmware version is 20230625.

[deleted]

Re: Zenbleed

#289

Post by myself248 »

c7DJTLrn wrote: post #78
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…

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.

I didn't demand more performance. My 2008-era AthlonX2 would still be relevant if web browsers hadn't gotten so bloated. I still use it for real desktop applications, i.e. everything that isn't in Electron.

Re: Zenbleed

#290

Post by toast0 »

zamadatix wrote: post #272
toast0 wrote: post #181

Earlier quoted context omitted.

> Fully dedicated cores aren't necessarily required because in the timesliced case the registers are unloaded and reloaded when different VMs are shuffled on and off the core. That said, they definitely prevent the cross-vm-data-leak case of this bug. Registers are unloaded and reloaded when different processes / threads are scheduled within a running VM too. That should protect the register contents, but because of…

Context switching for processes is done in software (i.e. the OS) via traps because TSS does not store all the registers and it doesn't offer a way to be selective to what the process actually needs to load (=slower). This limits its visibility to what's in the actively mapped registers as well as not guaranteeing the procedure even tries to reload all the registers. In this case, even if the OS does restore certain…

I can't easily find good documentation on the instructions you mentioned; but are you sure those save and load the whole register file, and not just the visible registers? There are some registers that are not typically explicitly visible, that I'd expect to also be saved or at least manipulable in a hypervisor, but just like the cache state isn't saved, I wouldn't expect the register file to be saved.

If we assume the register file isn't saved, just the visible registers, what's happening is the visible registers are restored, but the speculative dance causes one of the other values in the register file to become visible. If that's one of the restored registers, no big deal, but if it was someone else's value, there's the exploit.

If you look at the exploit example, the trick is that when the register rename happens, you are re-using a register file entry, but the upper bits aren't cleared, they're just using a flag to indicate the bits are cleared; then when rolling back the mispredicted vzeroupper unsets the flag, the upper bits of the register file entry are revealed.

Post reply on HN