[llvm-dev] _ExtInt, LLVM integers and constant time

[Roman Lebedev via llvm-dev]

On Wed, Apr 22, 2020 at 7:35 PM Adrien Guinet <aguinet at quarkslab.com> wrote:
>
> On 4/22/20 6:13 PM, Chris Lattner wrote:>> 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.
> >
>
> Okay that makes sense!
>
> If we would like, at some point, to introduce such guarantees, that would imply adding a
> "constant time" flag to the arithmetic operations at the LLVM IR level,
I don't think that will work. Normally, flags on instructions are
optimization hints
that can be freely dropped without affecting correctness. It's not going to be
really possible to ensure that every single existing&future fold
respects optional correctness-affecting flag.. I suspect this will involve
the similar approach as with constrained floating-point intrinsic.

> and have the
> backends honor it (which already seems the case), or fail if not possible ? .
I think so, yes.

> The only use case I have in mind that would benefit from this is cryptographic code, but
> there might be others.
>From previous discussions on the subject of constant time, i think
Chandler (CC'd)
has/is involved with some C++ paper about this.

Roman