linux-kernel - Re: better patch for linux/bitops.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 May 2016 22:18:09 +0000
From:	tytso@....edu
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	Jeffrey Walton <noloader@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, John Denker <jsd@...n.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Stephan Mueller <smueller@...onox.de>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Andi Kleen <andi@...stfloor.org>,
	Jason Cooper <cryptography@...edaemon.net>,
	linux-crypto@...r.kernel.org
Subject: Re: better patch for linux/bitops.h

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