Re:Constant-time coding will soon become infeasible
by hovav on Wednesday March 12, 2025 @04:09PM
(#43347186)
It's not guaranteed. See section 7 of https://www.usenix.org/system/files/conference/usenixsecurit...
Re:Constant-time coding will soon become infeasible
by manwe150 on Wednesday March 12, 2025 @02:04PM
(#43345997)
I wonder if you could have a compiler that intentionally pads every instruction to use a vector register pair of <value, slow-const>, so that every value gets paired with whatever constant or other expression will cause the slowest execution of that vector instruction and with the maximum latency chain. Otherwise, it does look like the VDIV instructions can have variable latencies based on the data itself (and not just spectre-like speculation issues on the memory access patterns).
Re:Constant-time coding will soon become infeasible
by Sesse__ on Wednesday March 12, 2025 @06:50PM
(#43348529)
You don't have any guarantee that the SIMD operations are actually done in parallel (which is of of the assumptions needed for “the latency matches that of the slowest element”). E.g., I believe VPGATHERDD is microcoded (and serial) on some CPUs, NEON (128-bit) is designed to be efficiently implementable by running a 64-bit ALU twice, AVX2 and AVX512 double-pumped on some (many) CPUs likewise…
Is that actually guaranteed? Having to do the whole vector doesn't necessarily mean the time can't vary for different values for complex operations. (like division)
I can't find the details, but https://gleissen.github.io/papers/iodine.pdf at least mentions "Dually, if timing variability is unavoidable, e.g., in SIMD or floating-point units, making this variability explicit can better inform..." so it sounds like simd is at least situation specific here.