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

11–20 of 62 posts

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

#11

Post by zzo38computer »

connicpu wrote: post #10
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 side channel from memory access timings are exactly why cmov is its own instruction on x86_64. It retrieves the memory regardless of the condition value. Anything else would change the timings based on condition. If you're going to segfault that's going to be visible to an attacker regardless because you're going to hang up.

I mean the possibility that the rest of the program guarantees that the address is valid if the condition is true but otherwise it might be valid or invalid. This is probably not important for most applications, but I don't know if there are some unusual ones where it would matter.

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

#12

Post by wahern »

connicpu wrote: post #10
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 side channel from memory access timings are exactly why cmov is its own instruction on x86_64. It retrieves the memory regardless of the condition value. Anything else would change the timings based on condition. If you're going to segfault that's going to be visible to an attacker regardless because you're going to hang up.

AFAIU, cmov wasn't originally intended to be a guaranteed constant-time operation, Intel and AMD won't commit to keeping it constant-time in the future, but it just so happened that at one point it was implemented in constant-time across CPUs, cryptographers picked up on this and began using it, and now Intel and AMD tacitly recognize this dependency. See, e.g., https://www.intel.com/content/www/us/en/developer/articles/t...

> The CMOVcc instruction runs in time independent of its arguments in all current x86 architecture processors. This includes variants that load from memory. The load is performed before the condition is tested. Future versions of the architecture may introduce new addressing modes that do not exhibit this property.

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

#13

Post by zzo38computer »

ethin wrote: post #9

So this makes me curious: is there a reason we don't do something like a __builtin_ct_begin()/__builtin_ct_end() set of intrinsics? Where the begin intrinsic begins a constant-time code region, and all code within that region must be constant-time, and that region must be ended with an end() call? I'm not too familiar with compiler intrinsics or how these things work so thought I'd ask. The intrinsic could be scoped…

Maybe it might be better to be implemented as a function attribute instead

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

#14

Post by fanf2 »

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)…

What happened to the blog post? It was moved and now it has disappeared :-(

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

#15

Post by ethin »

zzo38computer wrote: post #13
ethin wrote: post #9

So this makes me curious: is there a reason we don't do something like a __builtin_ct_begin()/__builtin_ct_end() set of intrinsics? Where the begin intrinsic begins a constant-time code region, and all code within that region must be constant-time, and that region must be ended with an end() call? I'm not too familiar with compiler intrinsics or how these things work so thought I'd ask. The intrinsic could be scoped…

Maybe it might be better to be implemented as a function attribute instead

Or a pragma? Like how OpenMP did it?

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

#16

Post by amluto »

Too bad that Intel chips more or less reserve the right to take LLVM’s nice output and make it non-constant-time anyway. See:

https://www.intel.com/content/www/us/en/developer/articles/t...

Sure, you could run on some hypothetical OS that supports DOITM and insert syscalls around every manipulation of secret data. Yeah, right.

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

#17

Post by jfindper »

layer8 wrote: post #8
jfindper wrote: post #3

Earlier quoted context omitted.

> 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…

“Sabotage” can be used in a figurative sense that doesn’t insinuate intent. An adjacent example is “self-sabotage”, which doesn’t imply intent.

Every dictionary I've looked at, wikipedia, etc. all immediately and prominently highlight the intent part. It really seems like the defining characteristic of "sabotage" vs. other similar verbs. But, language is weird, so, ¯\_(ツ)_/¯.

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

#18

Post by Meneth »

fanf2 wrote: post #14
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)…

What happened to the blog post? It was moved and now it has disappeared :-(

Archived copy here: https://archive.is/tIXt7

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

#19

Post by layer8 »

layer8 wrote: post #8
jfindper wrote: post #3

Earlier quoted context omitted.

> 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…

“Sabotage” can be used in a figurative sense that doesn’t insinuate intent. An adjacent example is “self-sabotage”, which doesn’t imply intent.

Since the sibling comment is dead and thus I can’t reply to it: Search for “unintentional sabotage”, which should illustrate the usage. Despite appearances, it isn’t an oxymoron. See also meaning 3a on https://www.merriam-webster.com/dictionary/sabotage.

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

#20

Post by JoshTriplett »

amluto wrote: post #16

Too bad that Intel chips more or less reserve the right to take LLVM’s nice output and make it non-constant-time anyway. See: https://www.intel.com/content/www/us/en/developer/articles/t... Sure, you could run on some hypothetical OS that supports DOITM and insert syscalls around every manipulation of secret data. Yeah, right.

Last I saw, it seemed like the plan was to unconditionally enable it, and on the off chance there's ever a piece of hardware where it's a substantial performance win, offer a way to opt out of it.
Post reply on HN