Daan Sprenkels via llvm-dev
2019-Sep-12 09:30 UTC
[llvm-dev] Side-channel resistant values
Hello all, Many of us are dealing with data that should remain secret on a daily basis. In my case, that's key material in cryptographic implementations. To protect against side-channel attacks. We write our code in such a way that the execution of the program is not dependent on the key and other secret values. However compiler optimizations often makes this very hard for us, and often our only resort is to fall back to writing in plain assembly. Let me give you an example: https://godbolt.org/z/b1-0_J In this code, the programmer instructs the program to select a value from the lookup table using a scanning approach, in an attempt to hide the secret lookup index in `secret_lookup_idx`. However, LLVM is smart and skips the memory lookups whenever i !secret_lookup_idx, exposing the function to cache side-channel attacks. Now how to prevent this? Most tricks, for example using empty inline assembly directives[1], are just ugly hacks. So I am wondering: Is there any support for preventing these kinds of optimizations? Or is there otherwise a "mostly recommended" way to prevent these optimizations? Thanks for your advice. All the best, Daan Sprenkels 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.
David Zarzycki via llvm-dev
2019-Sep-12 10:06 UTC
[llvm-dev] Side-channel resistant values
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.> 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 <https://youtu.be/nXaxk27zwlk?t=2472>>. See it in practice: > <https://godbolt.org/z/UMPeku <https://godbolt.org/z/UMPeku>> > [2]: <https://github.com/lmrs2/ct_choose <https://github.com/lmrs2/ct_choose>>, > <https://github.com/lmrs2/llvm/commit/8f9a4d952100ae03d06f10aee237bf8b3331da89 <https://github.com/lmrs2/llvm/commit/8f9a4d952100ae03d06f10aee237bf8b3331da89>>. > Later published at S&P18.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/91989f05/attachment-0001.html>
Finkel, Hal J. via llvm-dev
2019-Sep-12 16:18 UTC
[llvm-dev] Side-channel resistant values
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. -Hal On Sep 12, 2019, at 12:30 PM, Daan Sprenkels via llvm-dev <llvm-dev at lists.llvm.org<mailto: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 list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/8beb04d1/attachment-0001.html>