Adrien Guinet via llvm-dev
2020-Apr-22 06:35 UTC
[llvm-dev] _ExtInt, LLVM integers and constant time
Hello everyone, After reading the nice blog post about _ExtInt, I was wondering whether operations on i128/i256 and more generally on integer types in LLVM are guaranteed to be constant time or not. For instance, for now, the x86 & aarch64 backend generate constant time code for additions on i256 integers (see https://godbolt.org/z/xMfkqz & https://godbolt.org/z/jbkSpe), but is there some guarantee that this will always be the case? For instance one could add an early exit if the carry is zero at some point. One use case is cryptography code on elliptic curves, where you need this constant-time property to avoid side channel leakages. Such constant-time property would be nice and allow to directly use this extension, for which LLVM generates very efficient code (at least on x86/aarch64). Thanks everyone! -- Adrien.
Roman Lebedev via llvm-dev
2020-Apr-22 07:24 UTC
[llvm-dev] _ExtInt, LLVM integers and constant time
On Wed, Apr 22, 2020 at 9:35 AM Adrien Guinet via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hello everyone, > > After reading the nice blog post about _ExtInt, I was wondering whether > operations on i128/i256 and more generally on integer types in LLVM are > guaranteed to be constant time or not.I don't believe there's any such guarantee even for normal 8/16/32/64 -bit integers.> For instance, for now, the x86 & aarch64 backend generate constant time > code for additions on i256 integers (see https://godbolt.org/z/xMfkqz & > https://godbolt.org/z/jbkSpe), but is there some guarantee that this > will always be the case? For instance one could add an early exit if the > carry is zero at some point. > > One use case is cryptography code on elliptic curves, where you need > this constant-time property to avoid side channel leakages. Such > constant-time property would be nice and allow to directly use this > extension, for which LLVM generates very efficient code (at least on > x86/aarch64). > > Thanks everyone! > > -- > Adrien.Roman> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chris Lattner via llvm-dev
2020-Apr-22 16:13 UTC
[llvm-dev] _ExtInt, LLVM integers and constant time
> On Apr 22, 2020, at 12:24 AM, Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Apr 22, 2020 at 9:35 AM Adrien Guinet via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hello everyone, >> >> After reading the nice blog post about _ExtInt, I was wondering whether >> operations on i128/i256 and more generally on integer types in LLVM are >> guaranteed to be constant time or not. > I don't believe there's any such guarantee even for normal 8/16/32/64 > -bit integers.Right. I would expect this to be implementation / target dependent. The maximum bit width of an integer may also be target specific. For example, some targets may not provide a 1024 bit integer divide lib call, and may not want to open code it. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/540156fe/attachment.html>
Apparently Analagous Threads
- _ExtInt, LLVM integers and constant time
- LLVM Social - Paris: January 30th, 2018
- LoopVectorize fails to vectorize loops with induction variables with PtrToInt/IntToPtr conversions
- LLC Version 3.8 : Unsupported library call operation for a mul instruction
- LoopVectorize fails to vectorize loops with induction variables with PtrToInt/IntToPtr conversions