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

141–150 of 378 posts

Re: Zenbleed

#141

Post by nemetroid »

The README in the tar file with the exploit (linked at "If you want to test the exploit, the code is available here") contains some more details, including a timeline:

- `2023-05-09` A component of our CPU validation pipeline generates an anomalous result.

- `2023-05-12` We successfully isolate and reproduce the issue. Investigation continues.

- `2023-05-14` We are now aware of the scope and severity of the issue.

- `2023-05-15` We draft a brief status report and share our findings with AMD PSIRT.

- `2023-05-17` AMD acknowledge our report and confirm they can reproduce the issue.

- `2023-05-17` We complete development of a reliable PoC and share it with AMD.

- `2023-05-19` We begin to notify major kernel and hypervisor vendors.

- `2023-05-23` We receive a beta microcode update for Rome from AMD.

- `2023-05-24` We confirm the update fixes the issue and notify AMD.

- `2023-05-30` AMD inform us they have sent a SN (security notice) to partners.

- `2023-06-12` Meeting with AMD to discuss status and details.

- `2023-07-20` AMD unexpectedly publish patches, earlier than an agreed embargo date.

- `2023-07-21` As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.

- `2023-07-24` Public disclosure.

Re: Zenbleed

#143

Post by sp332 »

jrmg wrote: post #103
tremon wrote: post #100

Earlier quoted context omitted.

If you already have the package amd64-microcode installed (highly likely), then yes it will be updated automatically. https://packages.ubuntu.com/search?keywords=amd64-microcode

Great, thanks. Sort of weirds me out that my OS can just silently update my CPU - I didn’t realize I was giving it that level of control… I guess it’s good vs the alternative of no-one actually updating for exploits like his though.

Active microcode updates are stored in volatile memory and thus have to be applied during each system boot.

https://wiki.gentoo.org/wiki/Microcode

Re: Zenbleed

#145

Post by jrmg »

Thaxll wrote: post #122
jrmg wrote: post #103

Earlier quoted context omitted.

Great, thanks. Sort of weirds me out that my OS can just silently update my CPU - I didn’t realize I was giving it that level of control… I guess it’s good vs the alternative of no-one actually updating for exploits like his though.

It does not upgrade your cpu, it loads up the firemware when you boot Linux.

That’s reassuring, thanks (not sure why you’re getting downvoted!)

Re: Zenbleed

#146

Post by rcxdude »

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?

Basically never for anything that's at all CPU-bound, that growth in complexity is really the only thing that's been powering single-threaded CPU performance improvements since Dennard scaling stopped in about 2006 (and by that time they were already plenty complex: by the late 90s and early 2000's x86 CPUs were firmly superscalar, out-of-order, branch-predicting and speculative executing devices). If your workload can be made fast without needing that stuff (i.e. no branches and easily parallelised), you're probably using a GPU instead nowadays.

Re: Zenbleed

#147

Post by loeg »

winrid wrote: post #118
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…

Looks like my 2700x narrowly misses this one, assuming 7020 series is affected and not 7000 series.

Yeah -- Ryzen 2700x is Zen+, not Zen 2. Current understanding is that Zen+ is not affected.

Re: Zenbleed

#148

Post by darkwater »

javajosh wrote: post #95
eugene3306 wrote: post #87

Earlier quoted context omitted.

and how about playstation 5 ? and also xbox and that thing from valve?

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

Re: Zenbleed

#149

Post by loeg »

gavinhoward wrote: post #137

Off-topic question, but can some experts tell me why it is safe for `strlen()` and friends to use vector instructions when they can technically read out of bounds?

Essentially because memory mappings and RAM work at page granularity, rather than bytes. If a read from in-bounds in a page isn't going to fault, a read later in the same page isn't going to fault either (even if it is past the end of the particular object).

You can see this in glibc's implementation, which checks for crossing page boundaries: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... (line ~68)

Re: Zenbleed

#150

Post by brazzledazzle »

loeg wrote: post #102
account42 wrote: post #69

Earlier quoted context omitted.

Interesting, do you mind sharing what software you use to serve the static html and what kind of traffic its getting.

HTTP/1.1 200 OK Date: Mon, 24 Jul 2023 17:05:06 GMT Server: Apache

I do not miss performance tuning apache.
Post reply on HN