I seem to recall that this has come up on the mailing list before. It didn't seem like the LLVM developers had any interest at the time.
Conversation
Replying to
The code is wrong. You can't write i==secret_idx and expect it not to be a branch. Instead need something like a volatile array a, a[secret_idx]=-1; mask=a[i];
1
1
I guess that's bad unless it fits in a cache line though...
1
I always did things like ((a-b)|(b-a))>>31, which a good compiler with constant-time properties in mind would not convert to a branch, but I have no idea if LLVM would...
2
LLVM (and gcc, but less so) is pretty good at recovering "simpler" branches. __builtin_unpredictable helps a bit.
2
1
Seems like some volatile intermediates might be a cleaner way to block it.
1
Outside of compilers targeting embedded systems, I'm very hesitant to rely on volatile to do anything. It seems like the C standard gives license to the compiler to optimize out volatile accesses if it can prove the side effects aren't needed.
1
They can't generally justify removing writes though, since they could be used outside the process. Perhaps they can justify removing reads, but I think that's a bit sketchy. What if the read was going to fault, and the fault was going to be handled? There's a lot requiring this.
If the object has automatic storage they can know it won't.
1
. gave a good talk on volatile at cppcon m.youtube.com/watch?v=KJW_DL . Essentially, the spec says nothing. IMO, at some point it does become a clear quality of implementation issue.
1
1
That's not true if the type matches sigatomic_t or you allow (as extension) all volatile access from signal handlers. Then there's a hard requirement on any volatile object whose address leaks.
1
Show replies
In general, there's no way to write robust constant-time code in a language without a clear contract from the toolchain though. GCC and LLVM don't offer it. For example, what happens to supposedly constant-time code when using sanitizers? Even with asm, what does a CPU guarantee?
2
1
I think it's a problem that 'appears to work' is accepted as good enough and then a proper solution is never developed. Compiler developers / CPU vendors never even realize a lot of things are a problem where they should offer a solution. People don't care much about correctness.
1
3