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

351–360 of 378 posts

Re: Zenbleed

#351

Post by sgerenser »

alecco wrote: post #300
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…

Couldn't VMs zero all registers when switching? It shouldn't be much more latency than a typical context switch. Also purge CPU cache to be safe.

It does zero registers when context switching, but only the "logical" registers, not the physical ones, as described in this comment: https://news.ycombinator.com/item?id=36855266

Re: Zenbleed

#353

Post by flenserboy »

meepmorp wrote: post #246
Joker_vD wrote: post #233

Earlier quoted context omitted.

Looking at the IBM's tech from the sixties is somehow weirdly depressing: it's unbelievable how much of the architectural stuff they've invented already by the 1970.

I remember seeing VMware for the first time and thinking that the PC world had finally entered the 1970s.

So what might you say hasn't been brought in from the 80s yet?

Re: Zenbleed

#355

Post by skeggse »

insanitybit wrote: post #344
fulafel wrote: post #303

Earlier quoted context omitted.

Interesting. Physical cores or SMT virtual cores? Is there a link to their docs about this?

I honestly think I only ever saw an AWS Security Eng tweet about it lol sorry

https://docs.aws.amazon.com/whitepapers/latest/security-desi... seems like the relevant docs?

Re: Zenbleed

#356

Post by rockdoe »

anarazel wrote: post #221
Tuna-Fish wrote: post #84

Earlier quoted context omitted.

You are likely frequently running untrusted workloads. As javascript in a browser. I don't know about this one, but at least meltdown was fully exploitable from js. But yes, you are fine, 5950x is Zen3.

I wish Firefox would use PR_SCHED_CORE to reduce the likelihood of such leakage...

The idea being that the main process and content processes should never be on the same core?

I would worry about cross site leakage. From my understanding that would be unavoidable as soon as you have more tabs open than cores, which feels like an unworkable restriction.

Imagine opening a 9th tab and bring told you need to upgrade your 3700X to a 3900X.

Re: Zenbleed

#357

Post by anarazel »

rockdoe wrote: post #356
anarazel wrote: post #221

Earlier quoted context omitted.

I wish Firefox would use PR_SCHED_CORE to reduce the likelihood of such leakage...

The idea being that the main process and content processes should never be on the same core? I would worry about cross site leakage. From my understanding that would be unavoidable as soon as you have more tabs open than cores, which feels like an unworkable restriction. Imagine opening a 9th tab and bring told you need to upgrade your 3700X to a 3900X.

I think there's several levels. As a first step, I'd appreciate reducing the risk of javascript extracting contents from outside the browser. A second step could be to use more granular core scheduling within firefox, to prevent sharing cores that shouldn't be shared. A process/thread hierarchy can create multiple core scheduling groups.

Re: Zenbleed

#358

Post by kzrdude »

tremon wrote: post #100
jrmg wrote: post #89

AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it. I don’t really understand how CPU microcode updates work. If I’m keeping Ubuntu up to date, will this just happen automatically?

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

the security patch has now shown up in ubuntu and is visible in that packages listing, 3.20191218.1ubuntu2.1

Re: Zenbleed

#359

Post by nextaccountic »

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

Something is a little unclear to me. Does https://archlinux.org/packages/core/any/amd-ucode/

amd-ucode 20230625.ee91452d-5

last updated 2023-07-25 11:48 UTC

Contains the microcode update that addresses this?

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... says that the fixed version is 2023-07-18, but the amd-ucode version in Arch is 20230625.. but it was last updated in 2023-07-25..

My guess is that this is still getting the 20230625 firmware, per the PKGBUILD at https://gitlab.archlinux.org/archlinux/packaging/packages/li...

Which contains those lines

_tag=20230625

source=("git+https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...")

I suppose that it isn't up to date and thus Arch Linux is still vulnerable, right?

edit:

but actually there's two commits in the _backports array (which contains cherry-picked commits) that was last edited 20 hours ago

https://gitlab.archlinux.org/archlinux/packaging/packages/li...

Which is 0bc3126c9cfa0b8c761483215c25382f831a7c6f and b250b32ab1d044953af2dc5e790819a7703b7ee6

And b250b32ab1d044953af2dc5e790819a7703b7ee6 appears to be the commit I linked ealier at git.kernel.org so hopefully up-to-date Arch is not vulnerable to zenbleed

Re: Zenbleed

#360

Post by attentive »

slappy7 wrote: post #268

Anybody know how to disable the chicken bit on Windows? They're not planning to fix this until fucking December...

That's atrocious. Looks like microsoft doesn't care about AMD CPU as much as AMD doesn't care about windows.

As far as I can see there is no easy way to use MSR on windows.

Post reply on HN