llvm dev - Sep 2019 - 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.

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>

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>