4 ms·

I don't think it should, if the performance change only depends on immediates hardcoded into the binary, and not the variable data being processed. Maybe if the

I don't think it should, if the performance change only depends on immediates hardcoded into the binary, and not the variable data being processed. Maybe if the algorithm branched on the variable data and had two separate ways of loading something, but branching on variable data is the #1 thing you're supposed to avoid in the first place.

atq2119 2y ago
To expand on this a bit, the hypothesis stated elsewhere is that the register renamer stores "physical register + 11-bit signed immediate". It should be possible to construct scenarios where a logical register is mapped to "physical register + immediate" where the immediate depends on the path taken through the program so far. The easiest example would be an if-statement that optionally adds 1023 to a register, and then an add of 1 after the if-statement. The add of 1 overflows the immediate stored in the register renamer if and only if the if-condition was true. As you said, that requires taking different control flow paths through the program, which is something to be avoided by constant-time algorithms anyway. One potential twist: This shows that it may be important that the interface between the constant-time algorithm and the rest of the program goes entirely through memory and not through registers. If the interface does go through registers, it's possible that variable register-renamer-immediates leak from the outside world into the constant-time algorithm. (This admittedly feels like a bit of a stretch, but who knows.)
- Bulat_Ziganshin 2y ago
  just to make you even more paranoid - zen2/4 (and probably e-cores and zen5) can rename memory operands too (you start to do strange things when Intel limits you to 16 registers)! so today it needs to go through SSD or maybe the network LOL. but for real conspiracy, we should use paper and pencil

atq2119 2y ago

To expand on this a bit, the hypothesis stated elsewhere is that the register renamer stores "physical register + 11-bit signed immediate". It should be possible to construct scenarios where a logical register is mapped to "physical register + immediate" where the immediate depends on the path taken through the program so far. The easiest example would be an if-statement that optionally adds 1023 to a register, and then an add of 1 after the if-statement. The add of 1 overflows the immediate stored in the register renamer if and only if the if-condition was true. As you said, that requires taking different control flow paths through the program, which is something to be avoided by constant-time algorithms anyway. One potential twist: This shows that it may be important that the interface between the constant-time algorithm and the rest of the program goes entirely through memory and not through registers. If the interface does go through registers, it's possible that variable register-renamer-immediates leak from the outside world into the constant-time algorithm. (This admittedly feels like a bit of a stretch, but who knows.)

Bulat_Ziganshin 2y ago
just to make you even more paranoid - zen2/4 (and probably e-cores and zen5) can rename memory operands too (you start to do strange things when Intel limits you to 16 registers)! so today it needs to go through SSD or maybe the network LOL. but for real conspiracy, we should use paper and pencil