oskgo opened issue #5617:
Feature
Add support for doing cryptographic constant-time in cranelift.
A great introductory guide to cryptographic constant-time can be found at: https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html
Citing the main idea:
Secret information may only be used in an input to an instruction if that input has no impact on what resources will be used and for how long
Benefit
Enables giving higher assurances for cryptographic implementations by allowing them to be secured against or at least resistant to timing attacks.
Implementation
- Adding support for annotating "secret" values/identifiers
- Restricting optimizations and codegen involving these secrets
Caveats
- Performance is very important for cryptography, so the level of interest depends on whether it is possible to get comparable performance with Cranelift. This is not about how good Cranelift optimizes, but how well hand-optimized code that ends up in Cranelift can run in the best case.
- It is unlikely for cryptography to be written in cranelift IR itself, so the benefits of this proposal are unlikely to bear fruit until WASM or Rust get support.
bjorn3 commented on issue #5617:
It is unlikely for cryptography to be written in cranelift IR itself, so the benefits of this proposal are unlikely to bear fruit until WASM or Rust get support.
I guess fiat-crypto could get a Cranelift backend. That would give you a lot of elliptic curve implementations without too much effort. Still leaves other kinds of crypto primitives though.
oskgo commented on issue #5617:
Yes, and there are others that could get Cranelift back-ends that would then immediately benefit as well.
I guess my point is more that this proposal won't do much by itself and has to rely on what other projects do to get benefits.
Sadly this argument can be made by both sides. Someone has to take the first step.
jameysharp commented on issue #5617:
I wonder if adding this infrastructure might allow us to remove the
select_spectre_guard
variant of theselect
instruction? I'm imagining something like tagging the result of a bounds-check as "secret" before passing it toselect
.If constant-time operations can be a special case of the kind of optimization barrier we already need for Spectre mitigations, I think that would make it easier to justify maintaining this infrastructure before anybody else starts using it.
oskgo commented on issue #5617:
You couldn't remove the variant by making the select condition a secret without changing the abstract semantics.
select_spectre_guard
has sideffects, whileselect
doesn't, so IIUC the optimizer is free to remove calls toselect
very freely, while calls toselect_spectre_guard
can only be removed when an entire branch is removed.If
select_spectre_guard
having sideeffects is just a hack to prevent it being replaced with branches, then using a secret condition onselect
instead would actually be an improvement since it would allow deleting the instruction when it isn't needed. This also makes more sense, since conditional moves don't really have side effects, it's just the alternatives that might have them.
cfallin commented on issue #5617:
If select_spectre_guard having sideeffects is just a hack to prevent it being replaced with branches
Indeed it is a hack; the only restriction that's necessary is that it remains a cmove and is neither converted to a branchy form, nor is constant-propagated. (Well, I suppose cprop based on a statically constant value would preserve the speculation safety, but cprop from a path-sensitive constant past a branch would not.)
I very much like @jameysharp 's idea of subsuming this with a more general taintedness notion that ensures no branch depends on it!
Last updated: Dec 23 2024 at 12:05 UTC