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

161–170 of 378 posts

Re: Zenbleed

#161

Post by jeroenhd »

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.

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 that will let you rent dedicated CPU cores, but they often cost 4-5x more than a normal virtual CPU. Overprovisioning is how virtual servers are available for cheap!

Re: Zenbleed

#163

Post by IshKebab »

loeg wrote: post #99
eric__cartman wrote: post #59

This is incredibly scary. On my Zen 2 box (Ryzen 3600) logging the output of the exploit running as an unprivileged user while copying and pasting a string into a text editor in the background (I used Kate), resulted in pieces of the string being logged into the output of zenbleed. And this is after a few seconds of runtime mind you, not even a full minute. Thankfully the exploit is highly dependent on a specific asm…

> Thankfully the exploit is highly dependent on a specific asm routine so exploiting it from JS or WASM in a browser should be extremely difficult. Otherwise a nefarious tab left open for hours in the background could exfiltrate without an issue. At least one commentor here claims to be able to reproduce this with javascript: https://news.ycombinator.com/item?id=36849767 .

A very bold claim with zero evidence.

Re: Zenbleed

#164

Post by zamadatix »

Astronaut3315 wrote: post #115
astrange wrote: post #104

Earlier quoted context omitted.

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

This specific CVE still applies even if SMT is off, per the article.

In the context of this conversation, SMT on/off is relevant to what scope of the vulnerability has with VMs beyond the claim in the article that the issue is in some way present inside VMs.

Re: Zenbleed

#165

Post by zamadatix »

bbojan wrote: post #155
astrange wrote: post #104

Earlier quoted context omitted.

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.

In the context of this conversation, SMT on/off is relevant to what scope of the vulnerability has with VMs beyond the claim in the article that the issue is in some way present inside VMs.

Re: Zenbleed

#166

Post by KeplerBoy »

jeroenhd wrote: post #161
astrange wrote: post #104

Earlier quoted context omitted.

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

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.

Re: Zenbleed

#167

Post by cesarb »

brazzledazzle wrote: post #150
loeg wrote: post #102

Earlier quoted context omitted.

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

I do not miss performance tuning apache.

In my personal experience, the first step in tuning Apache was "put a nginx server in front of it". Running out of workers (either processes in the prefork model, or threads otherwise) was in my experience way too easy, especially when keepalive is enabled (even a couple of seconds of keepalive can be painful). The async model used by nginx can handle a lot more connections before running out of resources.

Re: Zenbleed

#168

Post by Night_Thastus »

dtx1 wrote: post #9
Night_Thastus wrote: post #7

Earlier quoted context omitted.

To be fair, flashing the bios isn't nearly as bad on most modern systems. Put the file on a USB drive, plug it in, restart and go into the bios, look for the flashing utility, select the file, done. As long as the machine is on a UPS in case of disaster, everything's accounted for.

From my experience: Better have a > 32gig USB Flash drive, everything else doesn't work (MSI) and I don't have an UPS so it's always quite an exciting experience. Especially since Motherboard Manifactures save almost a whole dollar by not having a display ouputting anything. So it's blinkenlights and hope for the best

Get a UPS!!

Not just for convenience, but safety. You don't want to be caught out when something goes wrong, even without flashing the bios.

A lot of boards these days have 7-segment displays. They're not great, but they're a good step up. Don't need to spend a lot, I think they show up on $300-ish boards. Mine definitely does.

Re: Zenbleed

#169

Post by zamadatix »

loeg wrote: post #94
zamadatix wrote: post #79

Earlier quoted context omitted.

In the case of the VM won't registers be wiped when entering/exiting the VM?

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.

Ah, this is a good point for those still using hypervisor schedulers which allow mapping different VMs to the same core.

Re: Zenbleed

#170

Post by href »

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.
Post reply on HN