linux-kernel - Re: [PATCH 2/5] CPU Jitter RNG: Enable compilation

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:	Tue, 4 Feb 2014 18:15:05 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Theodore Ts'o <tytso@....edu>,
	Jörn Engel <joern@...fs.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Ralf Baechle <ralf@...ux-mips.org>, dave.taht@...il.com,
	John Crispin <blogic@...nwrt.org>, andrewmcgr@...il.com,
	Thorsten Glaser <tg@...bsd.de>, sandyinchina@...il.com
Subject: Re: [PATCH 2/5] CPU Jitter RNG: Enable compilation

Hi!

On Tue, Feb 04, 2014 at 05:53:39PM +0100, Stephan Mueller wrote:
> Am Dienstag, 4. Februar 2014, 17:39:57 schrieb Hannes Frederic Sowa:
> >On Tue, Feb 04, 2014 at 05:19:52PM +0100, Stephan Mueller wrote:
> >> Also, I consider the execution speed of the entropy collection is not
> >> really an issue because the RNG delivers random numbers at a
> >> comparatively high rate. Any other noise source feeding into random.c
> >> delivers data with far less speed.
> >
> >Compiling the kernel with -O0 could add some other problems, like
> 
> I thought with the given flag, I only compile the respective C file 
> without optimizations, but not the entire kernel. Am I wrong here?

That's correct.

But your file is pretty long and now someone tries to use a static inline
function from one of the included headers which itself does some tests with
compiletime_assert. In some cases compiletime_assert does generate a call to
an external function which does not exist in the kernel but will be folded away
if the compiler can check that the condition in the assert is always true. It
is expected that the linking process fails in case the assert could not be
shown valid.

So in case you add -O0 and you eliminate some optimizations the compiler may
not eliminate those calls to the undefined functions and thus you could always
get a linking error.

If you need to compile something with -O0 try to just put the non-optimizing
code into a seperate file and try to eliminate as much dependencies and
headers as possible.

> >e.g. not doing enough constant folding which could result in linking
> >errors. I guess it is not a problem currently though, but some of the
> >compile time checks depend on this (compiletime_assert and such).
> 
> How do you think that my folding code can cause linking errors?

I thought about the compiler not doing enough constant folding not
you. ;) The kernel is known to not always compile with optimization
levels below -O2.

Greetings,

  Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/