There may already be sufficient ways to do boring C:
- Tool-focused: pick "any" C compiler (GCC) then turn on *all* of the
warnings, not just -Wall. Do the same with a "second" (clang) compiler. Add
an external Lint tool that checks formatting. Add a MISRA C rule checker.
Pay for some commercial static analysis tools. Wait for the boy who cried
wolf effect to settle in.
- Pro: compile chain stays the same.
- Con: verification toolchain bloat, dev process bloat, gap between
static analysis tools and actual compiler behavior (eg., some of MISRA C is
meant to mitigate broken embedded compilers, and provides dubious value on
a mature one.)
- Standards-focused: if you want Ada you know where to find it. Otherwise,
at the cost of portability there's CompCert/FRAMA-C CIL.
- Pro: decades of work on this very topic.
- Con: actual experience all comes from the commercial space. Possibly
some design by committee. Possibly limited portability.
If I'm guessing DJB's motivation correctly, his worst-case use case is a
bit extreme - avoiding timing side channels on a modern platform, with
optimizations and microcode and caches and out of order execution, is hard.
Writing in a safer C subset is doable.
On Mon, Dec 21, 2015 at 10:21 AM, Will Sargent <will.sarg...@gmail.com>
wrote:
> DJB on writing "boring" programs in C:
>
>
>> As a boring platform for the portable parts of boring crypto software,
>> I'd like to see a free C compiler that clearly defines, and permanently
>> commits to, carefully designed semantics for everything that's labeled
>> "undefined" or "unspecified" or "implementation-defined" in the C
>> "standard". This compiler will provide a comprehensible foundation for
>> people writing C code, for people auditing C code, and for people
>> formally verifying C code.
>> For comparison, gcc and clang both feel entitled to arbitrarily change
>> the behavior of "undefined" programs. Pretty much every real-world C
>> program is "undefined" according to the C "standard", and new compiler
>> "optimizations" often produce new security holes in the resulting object
>> code, as illustrated by
>> https://lwn.net/Articles/342330/
>> https://kb.isc.org/article/AA-01167
>> and many other examples. Crypto code isn't magically immune to this---
>> one can easily see how today's crypto code audits will be compromised by
>> tomorrow's compiler optimizations, even if the code is slightly too
>> complicated for today's compilers to screw up. A boring C compiler will
>> eliminate these nasty surprises; it will prioritize predictability.
>
>
> https://groups.google.com/d/msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ
>
> Will.
>
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss@mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
>
>
_______________________________________________
langsec-discuss mailing list
langsec-discuss@mail.langsec.org
https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
