Linux Developers Evaluating New "DOITM" Security Mitigation For Latest Intel CPUs

[microcode]

All of those constant time primitives are designed with the notion that the operands are constant time, which apparently is not the case for Intel and Arm anymore unless this new flag is set. So they are equally affected by this as AES.

What exactly do you mean? Integer addition now leaks timing information based on the values added? The shifts are static so there's no info there, and surely XOR is still constant... Right?

[hotaru]

What exactly do you mean? Integer addition now leaks timing information based on the values added? The shifts are static so there's no info there, and surely XOR is still constant... Right?

ADD, SHL, SHR, and XOR are all on the list of instructions that Intel says are guaranteed to be constant time only if DOITM is enabled. so without this mitigation enabled, they might not be constant-time.

[microcode]

ADD, SHL, SHR, and XOR are all on the list of instructions that Intel says are guaranteed to be constant time only if DOITM is enabled. so without this mitigation enabled, they might not be constant-time

Surely shifts of the same shift distance (the only kind in a ChaCha round) are constant time when the only difference is the register content... And XOR?
How did this happen?

[Developer12]

Surely shifts of the same shift distance (the only kind in a ChaCha round) are constant time when the only difference is the register content... And XOR?
How did this happen?

caching results based on operands would be enough to invalidate the timing. a superscalar cpu doing Tomasulo's algorithm has enough information available to do this for large blocks of cryptographic code. normally TA wouldn't look at the values of registers, but doing so could give it a huge boost.

processors aren't scalar anymore, so scalar assumptions don't matter.

[microcode]

caching results based on operands would be enough to invalidate the timing. a superscalar cpu doing Tomasulo's algorithm has enough information available to do this for large blocks of cryptographic code. normally TA wouldn't look at the values of registers, but doing so could give it a huge boost.

processors aren't scalar anymore, so scalar assumptions don't matter.

Surely it would be more expensive to cache basic integer operations based on register content, than to compute them... Plus, there are no branches nor any variable fetches, so the branch predictor and instruction scheduler have no reason to look at the values... I'll look into it, but the explanations you've given don't make sense to me.
The operands are the same every quarter round anyway, there is no information leaked from that.