Live data from Hacker News

Constant-time support coming to LLVM: Protecting cryptographic code

blog.trailofbits.com

61–62 of 62 posts

Re: Constant-time support coming to LLVM: Protecting cryptographic code

#61
post #55

Earlier quoted context omitted.

The one reason I can imagine to make it privileged-only is that it could be high-overhead to switch: if a CPU conditioned various kinds of predictors on it, it might have to flush those predictors when toggling it.

IMO the best design would be to keep the flag with the data. Give each register an extra bit indicating whether it’s sensitive. Any data-dependent-timing operation can’t possibly leak the data until the data is available to it, and that’s exactly when the ALU would find out that the data is sensitive anyway. No pipeline stalls.

Makes sense, but "give each register an extra bit" seems like something that would very easily get lost with a spill or any number of other ways.

Re: Constant-time support coming to LLVM: Protecting cryptographic code

#62
post #55

Earlier quoted context omitted.

IMO the best design would be to keep the flag with the data. Give each register an extra bit indicating whether it’s sensitive. Any data-dependent-timing operation can’t possibly leak the data until the data is available to it, and that’s exactly when the ALU would find out that the data is sensitive anyway. No pipeline stalls.

Makes sense, but "give each register an extra bit" seems like something that would very easily get lost with a spill or any number of other ways.

Sorry for necro-bumping, but there is a paper doing exactly that besides various other things to eliminate timing channels claiming also to prevent attacks based on speculative execution etc: "BLACKOUT : Data-Oblivious Computation with Blinded Capabilities" https://arxiv.org/abs/2504.14654. They basically utilize another bit of CHERI for "blinded capability" and methods to mitigate potential problems you identified.
Post reply on HN