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

201–210 of 378 posts

Re: Zenbleed

#201

Post by klyrs »

sedatk wrote: post #159
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.

It's good that they published patches early, isn't it?

Re: Zenbleed

#202

Post by kludge41 »

eric__cartman wrote: post #196
kludge41 wrote: post #194

Earlier quoted context omitted.

How do you build the POC? I get "No such file or directory" and error 127 on Ubuntu.

I had to run make on the uncompressed folder. Perhaps the build-essential package doesn't come with NASM in Ubuntu? I'll need a bit more info on the error if you want me to try and help you :)

After extracting the POC and installing build-essential, I still get this: nasm -O0 -felf64 -o zenleak.o zenleak.asm make: nasm: No such file or directory make: ** [Makefile:11: zenleak.o] Error 127

Re: Zenbleed

#203

Post by eric__cartman »

kludge41 wrote: post #202
eric__cartman wrote: post #196

Earlier quoted context omitted.

I had to run make on the uncompressed folder. Perhaps the build-essential package doesn't come with NASM in Ubuntu? I'll need a bit more info on the error if you want me to try and help you :)

After extracting the POC and installing build-essential, I still get this: nasm -O0 -felf64 -o zenleak.o zenleak.asm make: nasm: No such file or directory make: ** [Makefile:11: zenleak.o] Error 127

Install the nasm package. It's probably not included in build-essencial.

Re: Zenbleed

#204

Post by robryk »

klyrs wrote: post #201
sedatk wrote: post #159

Earlier quoted context omitted.

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

It's good that they published patches early, isn't it?

You'd want the delay between first publication of X and the microcode update making its way into releases of OSes to be smallest, for various values of X (mention of a vulnerability, microcode patch, description of vulnerability, PoC). Making various OS releasers aware that a microcode patch that fixes a vulnerability will be published on a given date before that date decreases that for most values of X.

Re: Zenbleed

#205

Post by taviso »

klyrs wrote: post #201
sedatk wrote: post #159

Earlier quoted context omitted.

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

It's good that they published patches early, isn't it?

Yes. It was unexpected, but good. Not a complaint.

Re: Zenbleed

#207

Post by [deleted] »

klyrs wrote: post #201
sedatk wrote: post #159

Earlier quoted context omitted.

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

It's good that they published patches early, isn't it?

[deleted]

Re: Zenbleed

#208

Post by mike_hearn »

href wrote: post #170

Can anyone explain the `wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))`? It seems to help on my system, but I don't understand what it does, and I don't know how to unset it.

CPU designers know that some features are risky. Much like how web apps may often have "feature flags" that can be flipped on and off by operators in case a feature goes wrong, CPUs have "chicken bits" that control various performance enhancing tricks and exotic instructions. By flipping that bit you disable the optimization.

Re: Zenbleed

#209

Post by stefan_ »

akyuu wrote: post #206

https://www.amd.com/en/resources/product-security/bulletin/a... According to AMD's security bulletin, firmware updates for non-EPYC CPUs won't be released until the end of the year. What should users do until then, disable the chicken bit and take the performance hit?

Are they out of their mind? This is not a "medium".

Re: Zenbleed

#210

Post by jeroenhd »

KeplerBoy wrote: post #166
jeroenhd wrote: post #161

Earlier quoted context omitted.

Not only do people do this, it's generally how VPS providers work. Most machines barely use the CPU most of the time (web servers etc.) so reserving a full CPU core for a VPS is horribly inefficient. It doesn't matter anyway, because SMT isn't relevant for this particular bug. With SMT allowing twice the cores on a CPU for most workloads, disabling it would double the cost for most providers! There are VPS providers…

Well you don't have to reserve any CPU Cores per VM. There's no law saying you can't have more VMs than logical cores. They're just processes after all and we can have thousands of them.

Of course not, but the vulnerability works by exploiting the shared register file so to mitigate this entire class of vulnerabilities, you'd need to dedicate a CPU core and as much of its associated cache as possible to a single VM.
Post reply on HN