2 ms·
Worst case execution times are generally unknowable, even at codegen. It depends on things like the specific microarchitectural details, what other instructions
by AlotOfReading 2y ago
Worst case execution times are generally unknowable, even at codegen. It depends on things like the specific microarchitectural details, what other instructions are currently executing, the memory hierarchy, what instructions have been executed before, how the power supply is responding, what the thermal environment is like, etc.
HAL/S dealt with these problems by a combination of programmer/validation discipline, custom hardware designed for hard real-time usecases, and generous support from the underlying RTOS (FCOS). Cryptography code doesn't deal with it, it just avoids data dependent nondeterminism, which is good enough for those use cases.
- gavinhoward 2y agoYes, you are correct. My idea is to cause a compile error if the backend can't use all instructions for which it knows the worst case latency or if it can't use purely constant-time instructions.
- AlotOfReading 2y agoThat's essentially every instruction though. You can't write a program that doesn't access memory for example, and every memory access is nondeterministic in wall clock time.
- gavinhoward 2y agoYes. In the crypto example, the backend would have to be sophisticated enough to know when the same addresses would be accessed every time, like bitslicing in AES. [1] The devil absolutely is in the details. This is why I say Yao's capabilities on this front are unproven. [1]: https://www.bearssl.org/constanttime.html#constant-time-in-bearssl https://www.bearssl.org/constanttime.html#constant-time-in-b...