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

371–378 of 378 posts

Re: Zenbleed

#371

Post by hedgehog »

asdfasgasdgasdg wrote: post #251
hedgehog wrote: post #229

Earlier quoted context omitted.

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).

I could be mistaken, but I don't think Zenbleed has anything to do with SMT, based on my reading of the document. There is a mention of hyperthreads sharing the same physical registers, but you can spy on anything happening on the same physical core, because the register file is shared across the whole core. It even says so in the document: Note that it is not sufficient to disable SMT. Apple's chips don't have this…

Correct, I was responding to parent writing "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?"

I think we may be seeing an industry-wide shift away from SMT because the performance penalty is small and the complexity cost is high, if so that fits parent's speculation about the trend. In a narrow sense Zenbleed isn't related to SMT but OP's question seems perfectly relevant to me. I come from a security background and on average more complicated == less secure because engineering resources are finite and it's just harder and more work to make complicated things correct.

Re: Zenbleed

#372

Post by anticensor »

paulmd wrote: post #35
gruez wrote: post #5

Earlier quoted context omitted.

No, it's all Zen 2 CPUs, which include both desktop CPUs (with or without integrated graphics, laptop CPUs, and server CPUs. The reason why the product list is so confusing is that AMD reuses architectures across generations. You'd think that all ryzen 5000 series CPUs have the same microarchitecture, but they don't). It's much easier to consult this list instead: https://en.wikipedia.org/wiki/Zen_2#Products

FYI this list isn't exhaustive. And I went to recommend the wikichips link and it's not exhaustive either. https://en.wikichip.org/wiki/amd/microarchitectures/zen_2#Al... Both of them are missing the newer 7000-family products with Zen2 like 7520U etc. https://www.amd.com/en/products/apu/amd-ryzen-5-7520u https://www.amd.com/en/products/apu/amd-ryzen-3-7320u https://www.amd.com/en/products/apu/amd-athlon-gold-7220u

Ryzen 7x2y are Zen 4 fused down to Zen 2, not originally taped out as Zen 2.

Re: Zenbleed

#373

Post by MauranKilom »

eru wrote: post #364
etmmte wrote: post #362

Earlier quoted context omitted.

You need certain instruction to exploit the vulnerability, if the switch statement doesn't use that then it is safe.

Hence my choice of phrasing: 'wouldn't necessarily protect you'. So, yes, the switch statemement might be safe, but you would need to prove that your switch statement doesn't use those instructions. You don't get to claim that for free just because you are using a switch-statement. Conversely, even if you execute bare metal instructions for the user of the VM, you could also deny those instructions to the user. Eg by…

Tangent: To deny those bare-metal instructions with static analysis, you might also have to flat out deny certain sequences of instructions that, when jumped to "unaligned" would also form the forbidden instruction. That might break innocent programs, no?

Re: Zenbleed

#374

Post by loeg »

Mahn wrote: post #368
loeg wrote: post #365

Earlier quoted context omitted.

Might just be parroting the claim from this thread, though.

I would think that Cloudflare is reputable enough that they would not state that claim without at least having some knowledge about it.

They have since rewritten that sentence from:

> The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.

https://web.archive.org/web/20230725020052/https://blog.clou...

To:

> Currently the attack can only be executed by an attacker with an ability to execute native code on the affected machine. While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.

https://web.archive.org/web/20230726204030/https://blog.clou...

I think I am vindicated -- they did just make that up, likely from the claim posted here.

Re: Zenbleed

#375

Post by Brybry »

akyuu wrote: post #348
themoonisachees wrote: post #341

Earlier quoted context omitted.

I am very doubtful that there exists any JavaScript that compiles to the specific instructions needed for this exploit.

It can be exploited through JavaScript according to CloudFlare: https://blog.cloudflare.com/zenbleed-vulnerability/

Cloudflare updated that post.

It previously read:

> The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.

Now it reads:

> Currently the attack can only be executed by an attacker with an ability to execute native code on the affected machine. While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.

Re: Zenbleed

#376

Post by eru »

MauranKilom wrote: post #373
eru wrote: post #364

Earlier quoted context omitted.

Hence my choice of phrasing: 'wouldn't necessarily protect you'. So, yes, the switch statemement might be safe, but you would need to prove that your switch statement doesn't use those instructions. You don't get to claim that for free just because you are using a switch-statement. Conversely, even if you execute bare metal instructions for the user of the VM, you could also deny those instructions to the user. Eg by…

Tangent: To deny those bare-metal instructions with static analysis, you might also have to flat out deny certain sequences of instructions that, when jumped to "unaligned" would also form the forbidden instruction. That might break innocent programs, no?

Simple: don't allow unaligned jumps. Google's NaCl already figured out how to do that ages ago. (Eg you could only allow jumps after a bit-masking operation. Details depends on architecture.)

But yes, unless you solve the halting problem, anything that bans all bad programs will also have false positives. It's the same with type systems in programming languages.

Re: Zenbleed

#377

Post by saagarjha »

Liquid_Fire wrote: post #245
saagarjha wrote: post #234

Earlier quoted context omitted.

Generally CHERI tracks things for 16-byte regions

I think you might be confusing the tracking of validity of capabilities themselves (which could indeed be at a 16 byte granularity for an otherwise 64-bit system) with the bounds of a capability, which can be as small as 1 byte.

Ah I think you are correct.

Re: Zenbleed

#378

Post by attentive »

attentive wrote: post #360
slappy7 wrote: post #268

Anybody know how to disable the chicken bit on Windows? They're not planning to fix this until fucking December...

That's atrocious. Looks like microsoft doesn't care about AMD CPU as much as AMD doesn't care about windows. As far as I can see there is no easy way to use MSR on windows.

I may be missing something, but since it basically exploits AVX that is easy to disable in win10.

bcdedit /set xsavedisable 1

and then reboot.

At least it fails the zenbleed POC.

Post reply on HN