Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Constant-time support coming to LLVM: Protecting cryptographic code

blog.trailofbits.com

Post reply on HN
Print view View original

51–60 of 62 posts

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

#51

Post by JoshTriplett »

cesarb wrote: post #50
amluto wrote: post #49

Earlier quoted context omitted.

A design such that it would actually make sense for a compiler to mark code that should permit data-dependent CPU optimizations differently from code that should not. This could be done using an opcode prefix, which would bloat code but would work perfectly. Or it could use an RFLAGS bit or a bit in MXCSR or a new register, etc. Almost anything would be better than an MSR that is only accessible to privileged code.

> Or it could use an RFLAGS bit or a bit in MXCSR or a new register, etc. > Almost anything would be better than an MSR that is only accessible to privileged code. ARM does that: their flag (DIT) is accessible by non-privileged code. If you know the architecture has that flag, either because your -march= is recent enough or because the operating system told you so through the hwcaps or the emulated id registers, you…

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.

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

#52

Post by soulbadguy »

jfindper wrote: post #3
frabert wrote: post #2

This has been a sore point in a lot of discussions regarding compiler optimizations and cryptographic code, how compilers and compiler engineers are sabotaging the efforts of cryptographers in making sure there are no side-channels in their code. The issue has never been the compiler, and has always been the language: there was never a way to express the right intention from within C (or most other languages, really)…

> how compilers and compiler engineers are sabotaging the efforts of cryptographers I'm not exposed to this space very often, so maybe you or someone else could give me some context. "Sabotage" is a deliberate effort to ruin/hinder something. Are compiler engineers deliberately hindering the efforts of cryptographers? If yes... is there a reason why? Some long-running feud or something? Or, through the course of thei…

As compiler have become more sophisticated, and hardware architecture more complicated, there are been a growing sentiment that some of the code transformation done by modern compiler make the code hard to reason about and to predict.

A lot of software engineer are seeing this as compiler engineer only caring about performance as opposed to other aspect such as debuggability, safety, compile time and productivity etc... I think that's where the "sabotage" comes from. Basically the focus on performance at the detriment of other things.

My 2 cents : The core problem is programmers expecting invariant and properties not defined in the languange standard. The compiler only garanty things as defined in the standard, expecting anything else is problematic.

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

#53

Post by anematode »

codedokode wrote: post #39
zzo38computer wrote: post #7

I think __builtin_ct_select and __builtin_ct_expr would be good ideas. (They could also be implemented in GCC in future, as well as LLVM.) In some cases it might be necessary to consider the possibility of invalid memory accesses (and avoid the side-channels when doing so). (The example given in the article works around this issue, but I don't know if there are any situations where this will not help.)

The names are pretty unattractive (which is not uncommon for C) though to the point one would want to avoid them in the code.

The solution is always another macro :)

#define ct_select __builtin_ct_select

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

#54

Post by anematode »

I'd love if this could make it into Rust... but I'm wondering if it'd be a bit of a burden on the creators of alternative backends (e.g. Cranelift), since if they implemented it naively, they would be unsuitable for compiling cryptographic code using it.

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

#55

Post by amluto »

JoshTriplett wrote: post #51
cesarb wrote: post #50

Earlier quoted context omitted.

> Or it could use an RFLAGS bit or a bit in MXCSR or a new register, etc. > Almost anything would be better than an MSR that is only accessible to privileged code. ARM does that: their flag (DIT) is accessible by non-privileged code. If you know the architecture has that flag, either because your -march= is recent enough or because the operating system told you so through the hwcaps or the emulated id registers, you…

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.

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

#56

Post by aw1621107 »

anematode wrote: post #54

I'd love if this could make it into Rust... but I'm wondering if it'd be a bit of a burden on the creators of alternative backends (e.g. Cranelift), since if they implemented it naively, they would be unsuitable for compiling cryptographic code using it.

> but I'm wondering if it'd be a bit of a burden on the creators of alternative backends (e.g. Cranelift)

Technically any new feature that requires backend support is an additional burden on backend devs. There's nothing special about constant-time builtins in this respect.

> since if they implemented it naively

Strictly speaking, whether an implementation is naive is independent of whether it is correct. An implementation that purports to be constant time while not actually being constant time is wrong, no matter how naive or sophisticated the implementation may be.

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

#57

Post by saagarjha »

thyristan wrote: post #34
saagarjha wrote: post #28

Earlier quoted context omitted.

Why would you like register and auto to have meaning?

Because for timing-sensitive code, those are important. If a variable is really a register, cache-based timing attacks just don't happen, because there is no cache in between.

I don’t think register has ever guaranteed that.

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

#58

Post by stingraycharles »

wat10000 wrote: post #22
stingraycharles wrote: post #21

Earlier quoted context omitted.

Sorry, I may be missing the point here, but reading that page doesn’t immediately make it obvious to me what that feature is. Is it some constant time execution mechanism that you can enable / disable on a per-thread basis to do… what exactly?

It turns off CPU features that could cause execution time to vary in a way that depends on the data being operated on.

Isn’t that exactly what you want for constant time algorithms? So why does the grandparent cite this article as Intel preventing LLVM’s techniques from working?

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

#59

Post by wat10000 »

stingraycharles wrote: post #58
wat10000 wrote: post #22

Earlier quoted context omitted.

It turns off CPU features that could cause execution time to vary in a way that depends on the data being operated on.

Isn’t that exactly what you want for constant time algorithms? So why does the grandparent cite this article as Intel preventing LLVM’s techniques from working?

I think the complaint is that this feature isn’t very practical to use (sounds like it needs OS support and a syscall to turn it on and off), and the fact that it exists implies that code that looks like it would be constant time may not be if this feature isn’t enabled.

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

#60

Post by westurner »

/? llvm.ct.select and __builtin_ct_select :

"Constant-Time Coding Support in LLVM: Protecting Cryptographic Code at the Compiler Level" (2025-10) PDF: https://llvm.org/devmtg/2025-10/slides/quick_talks/alexandre... :

> Circumvent Branch-base Timing Attacks

Post reply on HN