Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: anton@mips.complang.tuwien.ac.at Newsgroups: comp.compilers Subject: Re: Crypto friendly optimization? Date: Sun, 25 Aug 2024 16:06:00 +0000 Organization: Compilers Central Sender: johnl%iecc.com Approved: comp.compilers@iecc.com Message-ID: <24-08-008@comp.compilers> References: <24-08-003@comp.compilers> <24-08-004@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="23593"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, C, comment Posted-Date: 25 Aug 2024 13:30:20 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3589 Keith Thompson writes: >John R Levine 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]