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

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>

Hi Chandler,

The data-invariant feature sounds great but what about the general case? When
performance tuning code, people sometimes need the ability to reliably generate
CMOV, and right now the best advice is either “use inline assembly” or “keep
refactoring until CMOV is emited” (and hope that future compilers continue to
generate CMOV).

Given that a patch already exists to reliably generate CMOV, are there any good
arguments against adding the feature?

Dave

> On Sep 12, 2019, at 10:21 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> On Thu, Sep 12, 2019 at 9:18 AM Finkel, Hal J. via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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 <mailto: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 <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
<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.
>> 
>> 
>> 
>> _______________________________________________
>> 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
<https://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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20190913/517e5b8b/attachment.html>