[llvm-dev] Side-channel resistant values

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 12 12:21:43 PDT 2019


On Thu, Sep 12, 2019 at 9:18 AM Finkel, Hal J. via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 9/12/19 5:06 AM, David Zarzycki via llvm-dev wrote:
>
> I think adding a builtin to force CMOV or similar instructions on other
> architectures is long overdue. It’s generally useful, even if one isn’t
> mitigating speculative execution.
>
>
> I believe that you can currently get this effect using
> __builtin_unpredictable in Clang. __builtin_unpredictable wasn't added for
> this purpose, and it's a hint not a forced behavior, but I believe that it
> causes the backend to prefer cmov to branches during lowering.
>
I want to strongly advise against relying on this for anything to do with
cryptography. There are a lot of optimizations that I think will undo
this....

Sadly, I don't think we have any builtins that I think are reliable in this
way. I agree this is a critically important thing, but it isn't as simple
as exposing cmov IMO.

+Matthew Riley <mattdr at google.com> on my team is actually hoping to start
working on getting a real data-invariant programming model moving for C++
and part of that will involve adding support to LLVM as well, so I suspect
he'd be interested in this topic as well. Not sure what the timelines on
any of our lpans are at this point though, so can't really promise much.

For now, I'd really suggest using the techniques used by BoringSSL and
OpenSSL. Sadly, these predominantly rely on assembly. They do have some
constructs to use C/C++ code and ensure it remains data-invariant, but it
isn't because the constructs are actually reliable. Instead, they have
testing infrastructure that they continually run and that checks the
specific instruction stream produced by the compiler. Given the current
state, that's about the only reliable approach I know of.

-Chandler



>  -Hal
>
>
>
> On Sep 12, 2019, at 12:30 PM, Daan Sprenkels via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> PS. Perhaps, would there be interest to add such a feature to LLVM?
> I found this repository on GitHub[2], adding a `__builtin_ct_choose`
> intrinsic to clang. But as far as I know, this has never been upstreamed.
>
> [1]: Chandler Carruth described this trick at CppCon15:
> <https://youtu.be/nXaxk27zwlk?t=2472>. See it in practice:
> <https://godbolt.org/z/UMPeku>
> [2]: <https://github.com/lmrs2/ct_choose>,
> <
> https://github.com/lmrs2/llvm/commit/8f9a4d952100ae03d06f10aee237bf8b3331da89
> >.
> Later published at S&P18.
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/bca2ebf4/attachment.html>


More information about the llvm-dev mailing list