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

291–300 of 378 posts

Re: Zenbleed

#291

Post by jacquesm »

api wrote: post #269
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…

I’m quite surprised there hasn’t been a cloud apocalypse yet where something just runs rampant through AWS or something.

It's still early days for the cloud. I'm pretty sure such a thing will happen sooner or later.

Re: Zenbleed

#292

Post by jacquesm »

anarazel wrote: post #252
dTP90pN wrote: post #197

Earlier quoted context omitted.

More details: `good_revs` as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317... Currently published revs ("Patch") (git HEAD): https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... As of this writing, only two of the five `good_rev`s have been published.

What does that chicken bit do?

https://www.phoronix.com/news/Linux-AMD-Spectral-Chicken

Re: Zenbleed

#293

Post by srcreigh »

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.

The 6.4.6 kernel has mitigations, but the arch “linux” package is still at 6.4.5.

Re: Zenbleed

#294

Post by vetrom »

jlawer wrote: post #276
cduzz wrote: post #274

Earlier quoted context omitted.

Close, but not quite -- you can't nest the VMs the way you can on "big iron"

I know Nested Virtualisation is a thing on both KVM and hyper-v, what is different about what you could do on "big iron"

A VM nest in "big iron" isn't a special case. It's a context push with comparatively exhaustively defined costs, side effects, and implications.

Re: Zenbleed

#295

Post by vetrom »

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

Even before then, the sufficiently paranoid (but still bound to AWS for whatever reason) would track usage/steal/IO reporting along with best guesses for Amazon hardware expidenture and use that information to size instances to attempt to coincide with 1:1 node membership.

Re: Zenbleed

#296

Post by vetrom »

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…

Theres VLIW/'preprediction'/some other technical name I forget for infrastructures which instead ask you to explicitly schedule instruction/data/branch prediction. If I remember, the two biggest examples I can think of were IA64 and Alpha. I wanna think HP-PA did the same but I'm not clear on that one.

For various reasons, all these infras eventually lost out in the market due to market pressure (and cost/watt/IPC, I guess).

Re: Zenbleed

#297

Post by Dunedan »

infinityio wrote: post #116
hinkley wrote: post #50

Earlier quoted context omitted.

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.

It looks like this is a Zen 2-only exploit, so it shouldn't have any impact - AWS are likely already running hardware that isn't vulnerable to this

AWS does offer Zen 2 based EC2 instances though (C5a family for example).

Re: Zenbleed

#298

Post by stingraycharles »

phendrenad2 wrote: post #101
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…

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.

Isn’t the typical solution here to pin each VM to certain CPUs / cores?

Re: Zenbleed

#299

Post by [deleted] »

stingraycharles wrote: post #298
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.

Isn’t the typical solution here to pin each VM to certain CPUs / cores?

[deleted]

Re: Zenbleed

#300

Post by alecco »

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…

Couldn't VMs zero all registers when switching? It shouldn't be much more latency than a typical context switch. Also purge CPU cache to be safe.
Post reply on HN