Zeroing registers [LWN.net]

Zeroing registers

Posted Sep 25, 2021 18:44 UTC (Sat) by khim (subscriber, #9252)
In reply to: Zeroing registers by epa
Parent article: Two security improvements for GCC

No. On moderc CPU it's not trivial at all. Looks on Fog's tables. VZEROALL is either slow or really slow on modern CPUs

MOV register, #0 may have zero latency, but only if there are one such mov. Add dozen of them in row — and there would be noticeable slowdown. You forget about register renaming — it plays poorly with such instructions.

Zeroing registers

Posted Sep 26, 2021 3:26 UTC (Sun) by willy (subscriber, #9762) [Link] (2 responses)

Hm? I'm not a CPU expert, but I was under the impression that many CPUs have a zero register that they rename the zeroed register to. That's why it's a zero cycle instruction to zero a register (yes this sentence is too complicated; forgive me)

Zeroing registers

Posted Sep 28, 2021 21:16 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

But think about what you said one more time: how can you do anything in zero time? Anything at all? You can't. Everything computer does takes at least some resources and thus time.

Then how these instructions can ever be zero-latency/zero-time? μops fusion. Most programs don't zero-out register for the sake of zeroing-out registers. They zero-out register and then use it for something. And in such a case you can convert instruction which zero-out register with a simple mark in the other instruction which says “use zero as input instead of any real register”.

But instruction which clears dozen of registers is quite different. They need to, somehow, make physical registers zero. That is something you can just hide with μops fusion.

IOW: “make register zero” is fast (and sometimes even takes “zero time”) precisely in cases which we don't talk about when we are discussing these security-related zeroings.

Zeroing registers

Posted Sep 28, 2021 21:37 UTC (Tue) by willy (subscriber, #9762) [Link]

I didn't say it was free. I said it took zero cycles. That is, the CPU can do it in parallel with everything else, and it takes no extra time. There's a limit to how many registers can be renamed per cycle (see discussion here, for example: https://www.agner.org/optimize/blog/read.php?i=857#852
)

It's not related to uops fusion. Or at least it doesn't have to be. One way to implement register renaming could be to implement an array of register numbers, so that when your insn says "load r4", it looks up the physical register number in the 4th index and uses the 87th physical register. I'm not saying that's a good implementation, but it's one that could rename a lot of registers to zero very quickly.