On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote:
>
> I completely fail to see why tests or compiler versions should be
> part of the discussion. The C standard says the behaviour in
> certain cases is undefined, so a standard-compliant compiler
> can generate more-or-less any code there.
>
> As long as any of portability, reliability or security are among our
> goals, any code that can give undefined behaviour should be
> considered problematic.
Because compilers have been known not necessarily to obey the specs,
and/or interpret the specs in way that not everyone agrees with. It's
also the case that we are *already* disabling certain C optimizations
which are technically allowed by the spec, but which kernel
programmers consider insane (e.g., strict aliasing).
And of course, memzero_explicit() which crypto people understand is
necessary, is something that technically compilers are allowed to
optimize according to the spec. So trying to write secure kernel code
which will work on arbitrary compilers may well be impossible.
And which is also why people have said (mostly in jest), "A
sufficiently advanced compiler is indistinguishable from an
adversary." (I assume people will agree that optimizing away a memset
needed to clear secrets from memory would be considered adversarial,
at the very least!)
So this is why I tend to take a much more pragmatic viewpoint on
things. Sure, it makes sense to pay attention to what the C standard
writers are trying to do to us; but if we need to suppress certain
optimizations to write sane kernel code --- I'm ok with that. And
this is why using a trust-but-verify on a specific set of compilers
and ranges of compiler versions is a really good idea....
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
