Groups | Search | Server Info | Login | Register

Groups > comp.compilers > #3589

Re: Crypto friendly optimization?

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>John R Levine <johnl@taugh.com> writes:
>> On a cryptography list people were complaining that compiler optimizers
>> mess up their cryptographic code and make it insecure.  They try to write
>> code that runs in constant time, or that erases all the temporary storage,
>> but the compilers say oh, that's dead code, or oh, I can make this faster
>> with a few branches and the erases go away and the constatnt time isn't.
>>
>> This 2018 paper from Cambridge discusses changes they made to Clang/LLVM
>> so they could tell the compiler what they wanted it to do.  Has there been
>> other work on this topic?
>>
>C23 will add the memset_explicit() function :
>
>    The memset_explicit function copies the value of c (converted to an
>    unsigned char) into each of the first n characters of the object
>    pointed to by s. The purpose of this function is to make sensitive
>    information stored in the object inaccessible.
>
>I'm not aware of any current implementations that support it.

That's trivial:

void *memset_explicit( void *dest, int ch, size_t count )
{
  memset(dest, ch, count);
}

Yes, calls to such a memset_explicit() can be eliminated by an
adversarial compiler, but this makes such an implementation ideal for
such a compiler: there is nothing faster than an eliminated call, and
it satisfies the specification.  After all, if the data stored in the
area overwritten by memset_explicit is not accessible by a standard C
program without exercising undefined behaviour (a scenario ignored by
adversarial compilers), memset_explicit() does not change that, so an
adversarial compiler can "optimize" it away.  And if the memory is
accessible by a standard program, the compiler will not eliminate a
call to memset(), either.

Does it satisfy the purpose?  No, but it does wrt the C abstract
machine something that is equivalent (given the as-if rule and
assuming that no undefined behaviour is exercised) to the
specification, and that's the justification used for every misdeed of
adversarial compilers.

>[C11 has memset_s() which seems more or less the same thing.

Yes, someone told me that memset_s() is the solution to the problem of
clearing memory reliably.  Given that, why have they added
memset_explicit()?  The specification of memset_s() contains:

|Unlike memset, any call to the memset_s function shall be evaluated
|strictly according to the rules of the abstract machine as described
|in (5.1.2.3). That is, any call to the memset_s function shall assume
|that the memory indicated by s and n may be accessible in the future
|and thus must contain the values indicated by c.

In <2016Nov14.184256@mips.complang.tuwien.ac.at> I wrote about that:
|Now, everything else (including memset()) in the standard also is
|evaluated according to the rules of the abstract machine, and the
|"optimization" comes in afterwards, applies the as-if rule, and poof,
|memset() is gone, and so is memset_s().

Could it be that compilers do this with memset_s() and that's why C23
has added memset_explicit()?  And I expect that the same will happen
to memset_explicit(), too.

>I put the wrong link in the previous message.  The paper is
>here: https://ieeexplore.ieee.org/document/8406587 -John]

There was also a talk by Ilja van Sprundel at 35C3 about the problem
and he needed the full hour allocated to the talk.  The talk is called
"Memsad - why clearing memory is hard" and here are some links to it:

https://media.ccc.de/v/35c3-9788-memsad
https://www.youtube.com/watch?v=0WzjAKABSDk

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
[This all seems directed to leaving stuff in memory.  Anyone done work
on constant-time code? -John]

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Crypto friendly optimization? John R Levine <johnl@taugh.com> - 2024-08-24 17:14 -0400
  Re: Crypto friendly optimization? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-24 16:33 -0700
    Re: Crypto friendly optimization? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-24 20:55 -0700
    Re: Crypto friendly optimization? anton@mips.complang.tuwien.ac.at - 2024-08-25 16:06 +0000
      Re: Crypto friendly optimization? David Brown <david.brown@hesbynett.no> - 2024-08-25 21:12 +0200
      Re: Crypto friendly optimization? Philipp Klaus Krause <pkk@spth.de> - 2025-04-05 19:50 +0200
  Re: Crypto friendly optimization? Ian Lance Taylor <ianlancetaylor@gmail.com> - 2024-08-24 20:14 -0700
  Re: Crypto friendly optimization? David Brown <david.brown@hesbynett.no> - 2024-08-25 12:32 +0200

csiph-web