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

251–260 of 378 posts

Re: Zenbleed

#251

Post by asdfasgasdgasdg »

hedgehog wrote: post #229
Tuna-Fish wrote: post #80

Earlier quoted context omitted.

> At what point does the complexity of CPU architectures become so difficult to reason about that we just accept the performance penalty of keeping it simpler? Never for branch prediction. It just gets you too much performance. If it becomes too much of a problem, the solution is greater isolation of workloads.

In certain cases isolation and simplicity overlap, I suspect for example that the dangers of SMT implementation complexity are part of why Apple didn't implement it for their respective CPUs. Likely we'll see this elsewhere too, for example Amazon may not ever push to have SMT in their Graviton chips (the early generations are off the shelf cores from ARM where they didn't have a readily available choice).

I could be mistaken, but I don't think Zenbleed has anything to do with SMT, based on my reading of the document. There is a mention of hyperthreads sharing the same physical registers, but you can spy on anything happening on the same physical core, because the register file is shared across the whole core.

It even says so in the document:

    Note that it is not sufficient to disable SMT.
Apple's chips don't have this vulnerability, but it's not because they don't have SMT. They just didn't write this particular defect into their CPU implementation.

Re: Zenbleed

#252

Post by anarazel »

dTP90pN wrote: post #197
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…

More details: `good_revs` as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317... Currently published revs ("Patch") (git HEAD): https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... As of this writing, only two of the five `good_rev`s have been published.

What does that chicken bit do?

Re: Zenbleed

#254

Post by serf »

jahsome wrote: post #220
wolf550e wrote: post #182

Earlier quoted context omitted.

A Grandchild's Guide to Using Grandpa's Computer a.k.a. "If Dr. Zeuss were a Technical Writer" was written in 1994 and mentions microcode. Microcode updates are always discussed when talking about microarchitectural security vulnerabilities (and other scary CPU errata like https://lkml.org/lkml/2023/3/8/976 ). Microcode is always mentioned when discussing CPU design evolution.

It's funny that it's "always" mentioned, yet it's not familiar to me. Also curious the Wikipedia article for CPU design doesn't mention it, since it's "always" referenced. Just because something is familiar to you, or even large swaths of a given population, doesn't mean everyone should be expected to know it. I love learning new things. I love discovering topics I know nothing about, and I love picking the brains of…

> It's funny that it's "always" mentioned, yet it's not familiar to me. Also curious the Wikipedia article for CPU design doesn't mention it, since it's "always" referenced.

you're not going to convince others that microcode is some kind of foreign concept to CPUs just because you yourself were unfamiliar.

Yes, it can be a downer to discover that you're more naive in a subject than you had previously thought you were more familiar.

>Also curious the Wikipedia article for CPU design doesn't mention it, since it's "always" referenced.

microcode is something that is implemented by CPUs that are too big and expensive to replace -- it's not something that is fundamental to processor designs. It's something we now live with to prevent things like the 'pentium bug' from costing Intel many-many dollars after a consumer-products forced recall/replacement.

At this point in history I think that if someone wants to consider themselves to be well-versed or knowledgeable about consumer CPUs then learning about microcode is a hard requirement. It's a false metaphor now to consider a CPU to be an unchanging entity, and that's important to at least be aware of -- it's literally one of the only ways that t

Since wikipedia is the source du joure, here : https://en.wikipedia.org/wiki/Microcode

p.s. : I think it's a strange as you that the processor wiki page doesn't at least mention microcode, I guess they're trying to keep it 'pure'.

Re: Zenbleed

#255

Post by meithecatte »

hedgehog wrote: post #229
Tuna-Fish wrote: post #80

Earlier quoted context omitted.

> At what point does the complexity of CPU architectures become so difficult to reason about that we just accept the performance penalty of keeping it simpler? Never for branch prediction. It just gets you too much performance. If it becomes too much of a problem, the solution is greater isolation of workloads.

In certain cases isolation and simplicity overlap, I suspect for example that the dangers of SMT implementation complexity are part of why Apple didn't implement it for their respective CPUs. Likely we'll see this elsewhere too, for example Amazon may not ever push to have SMT in their Graviton chips (the early generations are off the shelf cores from ARM where they didn't have a readily available choice).

Eh, as long as you assign both hyper-threads to the same tenant, and schedule them at the same time, you should be fine.

Re: Zenbleed

#256

Post by adrian_b »

dontlaugh wrote: post #243
adrian_b wrote: post #96

Earlier quoted context omitted.

Because unless you pin the threads to certain CPU cores (e.g. in Linux by using the taskset command, or in Windows by using the Set Affinity command in Task Manager), they are migrated very frequently between cores. So even with SMT disabled, each core will execute sequentially many threads, switching every few milliseconds from one thread to another, and each context switch does not modify the hidden registers, it j…

Pinning doesn’t help either, since there will always be more threads than cores. Scheduling all those threads and even blocking on IO will cause context switches.

I do not know how that is done in Windows, but in Linux it is possible to reserve some cores to be used only for the threads that you assign to them and for no other threads.

This is done frequently for high-performance applications.

Re: Zenbleed

#257

Post by yakubin »

wolf550e wrote: post #198
yakubin wrote: post #108

Earlier quoted context omitted.

FWIW, enabling gzip/zstd compression in your HTTP server could help.

Only with something like mod_asis ( https://httpd.apache.org/docs/2.4/mod/mod_asis.html ) to serve already compressed content. Actually running zlib on every request will only make it worse.

> Actually running zlib on every request will only make it worse.

I wouldn't be so sure, given that without zlib HTTP connections take longer, thereby increasing the size of the wait queue and the number of parallel connections.

Re: Zenbleed

#259

Post by ChadNauseam »

loeg wrote: post #152
jrmg wrote: post #103

Earlier quoted context omitted.

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.

The implication was that you could boot a malicious OS, then boot into a different OS with the same processor and get pwned. As other commenters mentioned, this mechanism doesn't create that risk because the update has to be applied each boot.

Re: Zenbleed

#260

Post by mr_toad »

msla wrote: post #191
phendrenad2 wrote: post #101

Earlier quoted context omitted.

The problem is, VMs aren't really "Virtual Machines" anymore. You're not parsing opcodes in a big switch statement, you're running instructions on the actual CPU, with a few hardware flags that the CPU says will guarantee no data or instruction overlap. It promises! But that's a hard promise to make in reality.

This is because VM means two different things and has for a long time: IBM's VM was and is a hypervisor. It dates to the mid 1960s, in the form of CP-40, and it didn't run opcodes in software, but in hardware. https://en.wikipedia.org/wiki/IBM_CP-40 p-code machines, which interpret bytecode, date back almost as far, such as the O-code machine for BCPL. https://en.wikipedia.org/wiki/BCPL Getting people to distinguish…

> Getting people to distinguish between these concepts is probably a lost cause.

I think people here of all places should distinguish between these concepts.

There are big performance and security implications of the two approaches.

Post reply on HN