Re: explicit_bzero and -std=c99

[Bruno Haible]

Hi Simon,

> 1) Does gnulib support building with gcc -std=c99?  I think we should,
> but it could have documented missing functionality or breakage.

No, Gnulib does not support this. We freely use GCC extensions,
such as ({...}) or asm, usually conditionalized with
  defined __GNUC__ || defined __clang__
Only in math.in.h and xalloc-oversized.h we also test __STRICT_ANSI__.

We could test __STRICT_ANSI__ also in more places, but what really is the
point? So that people then complain "the asyncsafe-spin and simple-atomic
tests fail for me"?

The point of '-std=c99' is to verify that the source code is pure ISO C
without any extensions. Gnulib is not in that category.

> 2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for
> GCC, which isn't working in non-GNU modes of gcc.

In lib/explicit_bzero.c you see that we need to defeat compiler optimizations.
'asm' lets us formulate a memory barrier. Without 'asm' we have a fallback
code that defeated compiler optimizations at the time it was written, but
that will break in the long run as compilers are becoming better.

> Further wondering:
> 
>    1) The reason for having explicit_bzero is read_file, which needs it
>    for reading sensitive files, a feature we don't use.  Uncoupling this
>    unnecessary dependency would have been nice.

No, we have explicit_bzero because it's a glibc function that we think
should be available to programs on all OSes.
<https://www.gnu.org/software/gnulib/manual/html_node/explicit_005fbzero.html>

>    2) Is there no other way to implement explicit_bzero without 'asm'?
>    There is a another fallback code using volatile pointers, but I'm not
>    sure it really has the same semantics.

That's the point, exactly: Here 'asm' is necessary.

>    3) Is there a way to detect if the compiler supports 'asm'?  The
>    current test 'defined __GNUC__ && !defined __clang__' is what is
>    really failing here.

Probably something like
  (defined __GNUC__ || defined __clang__) && !defined __STRICT_ANSI__

> 3) Is the idiom of using separate functions bzero() vs explicit_bzero()
>    to avoid security-problematic compiler optimization still a good one?
> 
>    1) If yes, I think we should have read_sensitive_file() rather than
>    extending read_file() with a flag for this purpose.
> 
>    2) If no, what is the better idiom to use here instead of
>    explicit_bzero?

When the code for average contexts and the code for secure contexts differ
only by a few lines of code, we would like to avoid code duplication. As
code duplication means twice the maintenance effort in the future.

Things would be different when you want the code for secure contexts to
use exactly the same instructions (just with different data), regardless
of the input data.[1] Since code for average contexts is typically written
to minimize the number of instructions depending on the input data, this
would imply different algorithms and different code. But we are not in this
case here.

Bruno

[1] https://en.wikipedia.org/wiki/Timing_attack