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

321–330 of 378 posts

Re: Zenbleed

#321

Post by lmz »

myself248 wrote: post #289
c7DJTLrn wrote: post #78

Earlier quoted context omitted.

We demanded more performance and we got what we demanded. I doubt manufacturers are going to walk back on branch prediction no matter how flawed it is. They'll add some more mitigations and features which will be broken-on-arrival.

I didn't demand more performance. My 2008-era AthlonX2 would still be relevant if web browsers hadn't gotten so bloated. I still use it for real desktop applications, i.e. everything that isn't in Electron.

Your Athlonx2 already had branch prediction. https://chipsandcheese.com/2022/07/28/amds-athlon-64-getting...

Re: Zenbleed

#323

Post by cduzz »

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"

In the early days of virtualization on PCs (things like OS/2's dos box) the VM was 100% a weird special case VM that wasn't even running the same mode (virtual 8086 vs 286 / 386 mode), and that second-class functionality continued through the earlier iterations of "modern" systems (vmware / kvm / xen).

"PC" virtualization's getting closer to big iron virtualization, but likely will never quite get there.

Also -- I was running virtual machines on a 5150 PC when it was a big fast machine -- the UCSD P System ran a p-code virtual machine to run p-code binaries which would run equally well on an apple 2. In theory.

Re: Zenbleed

#324

Post by xinayder »

I read the article and I really liked that the author tried to make it seem as simple as possible that you don't need a degree or a deep understanding of how CPUs work to understand the issue.

However, one thing that bothers me is that the author claims it's possible to retrieve private keys or root passwords by triggering a faulty revert from the instruction that resets the upper bits of a register. Where is the demo results? All I see is a small-enough gif that looks like the Matrix terminal text scrolling through. Is there any way (other than running the exploit program myself) to check the results and see that it actually leaked the root password and other information?

Re: Zenbleed

#325

Post by jahsome »

marmakoide wrote: post #287
jahsome wrote: post #125

Earlier quoted context omitted.

I'm not sure five year olds know what microcode is. I'm 35, been in tech nearly 20 years and don't recall having heard that specific term before today.

I can explain to a 35 years old in tech. A modern generalist CPU is made of many smaller, simpler, specialized CPUs : there's a whole orchestra inside. Amongst those smaller CPUs, there's a master : it'll see to decoding of instruction, sending jobs to the various CPU units, and fetching the results of said jobs. That master is running a program, executing ... microcode ! And of course, if there is a program, there a…

Thank you for the great explanation! :)

Re: Zenbleed

#326

Post by saurik »

LtdJorge wrote: post #183
sounds wrote: post #160

Earlier quoted context omitted.

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.

What? The researcher that found it and wrote the article already posted a PoC that can be used to farm data from VMs in any VPS provider.

I would like to think that the likelihood of being able to find a juicy target using one of these specific CPUs and who would have explicitly not updated their microcode for this exploit is much much much higher going after end users on the web than by attacking organized VPS providers.

Re: Zenbleed

#327

Post by petters »

tempaccount420 wrote: post #312
stingraycharles wrote: post #298

Earlier quoted context omitted.

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

That's not very convenient. I want docker to be able to use all my cores when I build an image.

Docker is not a VM. It uses the same kernel as the host

Re: Zenbleed

#328

Post by c7DJTLrn »

saagarjha wrote: post #225
c7DJTLrn wrote: post #71

Earlier quoted context omitted.

Running untrusted code whether in a sandbox, container, or VM, has not been safe since at least Rowhammer, maybe before. I believe a lot of these exploits are down to software and hardware people not talking. Software people make assumptions about the isolation guarantees, hardware people don't speak up when said assumptions are made.

That is not true in this case. It's just a CPU bug; not even a side channel.

The statement about isolation guarantees is in general, doesn't relate to the OP.

Re: Zenbleed

#329

Post by ZeKK14 »

xinayder wrote: post #324

I read the article and I really liked that the author tried to make it seem as simple as possible that you don't need a degree or a deep understanding of how CPUs work to understand the issue. However, one thing that bothers me is that the author claims it's possible to retrieve private keys or root passwords by triggering a faulty revert from the instruction that resets the upper bits of a register. Where is the dem…

The exploit will leak more or less random data (data which was accessed recently by the CPU). You cannot target a specific part of the memory, but you can keep fetching data until you get something interesting.

Re: Zenbleed

#330

Post by userbinator »

dTP90pN wrote: post #192

> AMD have released an microcode update for affected processors. I don't think that is correct. AMD has released a microcode update[0] for family 17h models 0x31 and 0xa0, which corresponds to Rome, Castle Peak and Mendocino as per WikiChip [1]. So far, there seems to be no microcode update for Renoir, Grey Hawk, Lucienne, Matisse and Van Gogh. Fortunately, the newly released kernels can and do simply set the chicken…

and Mendocino

That's the same codename Intel used for Celerons 24 years ago, the ones famous for 50% overclocks:

https://ark.intel.com/content/www/us/en/ark/products/codenam...

Post reply on HN