Linux Reworks AMD Zen 1 Divide-By-Zero Mitigation After Original Fix Inadequate

[elml]

... Maybe, if more of the complexity in the hardware were exposed to software, some of it could be moved into the software. Compilers already have crude models of CPUs schedulers and execution resources, so why not make it explicit?...

That idea was called Itanium...

Instead, go explicitly parallel algorithms?

Or at least make good use of pipelining??

Regards,
Martin

[coder]

That idea was called Itanium...

Yes, I've read lots about IA64. That was one approach. They ran into problems for a variety of reasons, not all of them technical.

Also, it was over 20 years ago, and both CPUs and software have advanced considerably. I think someone could have more success today, especially with the benefit of hindsight.

Instead, go explicitly parallel algorithms?

Not sure exactly what you mean, but if you had an ISA that exposed the parallelism and concurrency of the CPU, then you could certainly harness that to better implement parallel code.

If you're dealing with something that maps well to SIMD, then GPUs are a better approach and becoming ever more ubiquitous.

Or at least make good use of pipelining??

I've previously done software pipelining, but modern CPUs make it almost pointless (like loop unrolling). They have such large speculative windows that they can look several loop iterations in the future and pipeline everything that's eligible.

[Findecanor]

I'm a bit confused about the details about this bug.

Q1: Does this bug mean that RDX:RAX are clobbered by the result of a previous division when the #DE exception fault handler is entered? Or does this bug only pass the error to speculatively executed code?

Q2: Does it affect only division by zero, or does it also happen on overflow? (such as MININT / -1)

[oleksii_o]

I'm a bit confused about the details about this bug.

Q1: Does this bug mean that RDX:RAX are clobbered by the result of a previous division when the #DE exception fault handler is entered? Or does this bug only pass the error to speculatively executed code?

Q2: Does it affect only division by zero, or does it also happen on overflow? (such as MININT / -1)

It's a speculative leak, not a functional issue. Division by zero on vulnerable CPUs speculatively assigns a stale value to RDX (stale value == a value that depends on the operands of an older non-faulting division). It affects only div by zero.

This leak is described in more details in this paper, Sec. 8.2.1: usenixsecurity23-hofmann.pdf . The only caveat, the paper claims that data cannot leak from kernel to user space; apparently, it's not the case given that the kernel patch was required.