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

151–160 of 378 posts

Re: Zenbleed

#151

Post by brazzledazzle »

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,…

Could even host on github pages with a cname.

Re: Zenbleed

#152

Post by loeg »

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.

As opposed to updating any other piece of software in the system directly? The OS has always had full control.

Re: Zenbleed

#153

Post by loeg »

heywhatupboys wrote: post #140
hinkley wrote: post #121

Earlier quoted context omitted.

The way Spectre and Meltdown played out, you'll have to excuse me if I stand outside the blast radius while we figure out if there's a chapter 2, 3 or 4 to this story. They've proven Zen 2 has this problem. They haven't proven no other AMD processors have it. A bunch of people looking to make names for themselves are probably busily testing every other AMD processor for a similar exploit.

> The way Spectre and Meltdown played out, you'll have to excuse me if I stand outside the blast radius while we figure out if there's a chapter 2, 3 or 4 to this story. I am OOTL on this one, do you have some information you could share?

There has been a long trickle of similar bugs to Spectre/Meltdown coming out long after the initial bugs and "fixes" were published. (The early fixes were all, in some sense, incomplete.)

Re: Zenbleed

#154

Post by gavinhoward »

loeg wrote: post #149
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)

Ah, so that's why there is special code in Valgrind to handle glibc and friends!

Re: Zenbleed

#155

Post by bbojan »

astrange wrote: post #104
loeg wrote: post #94

Earlier quoted context omitted.

The problem is the freed entries in the register file. A VM can, at least, use this bug to read registers from a non-VM thread running on the adjacent SMT/HT of a single physical core. I suspect a VM could also read registers from other processes scheduled on the same SMT/HT.

Are people running multiple untrusted VMs without turning SMT off? Even letting them share caches seems like asking for trouble.

The fine article states that simply turning off SMT doesn't help with this particular exploit.

Re: Zenbleed

#156

Post by FirmwareBurner »

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

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.

Re: Zenbleed

#157

Post by evandale »

heywhatupboys wrote: post #144
CyberDildonics wrote: post #127

Earlier quoted context omitted.

Might you explain how that would prove anything?

effort to lie on a text comment << effort to lie with a video

We are on a tech site with highly intelligent individuals who have been programming computers since we've been in diapers.

If you don't believe the text then how would you believe the video? Anything can be done in devtools beforehand and I can think of a million different ways to fake the video.

Personally, if I didn't trust the text then an easily faked video wouldn't placate me either.

Re: Zenbleed

#158

Post by jwilk »

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,…

It's a static file. You need to compress it only once, not for every response.

Re: Zenbleed

#159

Post by sedatk »

nemetroid wrote: post #141

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

> AMD unexpectedly publish patches, earlier than an agreed embargo date.

> As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.

AMD had to drop the ball somewhere didn't it.

Re: Zenbleed

#160

Post by sounds »

Sohcahtoa82 wrote: post #93
sounds wrote: post #38

Earlier quoted context omitted.

I was able to reproduce the vulnerability using javascript on a webpage. Therefore, no.

PoC || GTFO

OP here hadn't even bothered to read the article. That's the context of my reply. No PoCs going online so close to the disclosure, sorry.
Post reply on HN