[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5305CFD7.5060600@redhat.com>
Date: Thu, 20 Feb 2014 10:50:15 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Jörn Engel <joern@...fs.org>,
Theodore Ts'o <tytso@....edu>
CC: "H. Peter Anvin" <hpa@...or.com>,
Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
macro@...ux-mips.org, ralf@...ux-mips.org, dave.taht@...il.com,
blogic@...nwrt.org, andrewmcgr@...il.com, smueller@...onox.de,
geert@...ux-m68k.org, tg@...bsd.de
Subject: Re: [PATCH,RFC] random: collect cpu randomness
Il 02/02/2014 21:36, Jörn Engel ha scritto:
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wuninitialized"
> + input[0] ^= cycles ^ jiffies;
> + input[1] ^= (unsigned long)caller;
> + input[2] ^= (unsigned long)val;
> + input[3] ^= (unsigned long)&input;
> +#pragma GCC diagnostic pop
Your tests demonstrate that this works, and presumably you have checked
the assembly too. Still, this is invoking undefined behavior and the
compiler could justifiably change those "^=" to "=".
An "asm" would be a safer way to convince the compiler that input[] is
now initialized:
asm volatile ("" :
"=m" (input[0]), "=m" (input[1]),
"=m" (input[2]), "=m" (input[3]));
and *really* XOR the values into the contents of the stack.
Of course the compiler could still have a "feature" where it
pre-initializes the whole stack frame with some kind of canary, but that
would be a problem even with your version of the code.
Paolo
--
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/
Powered by blists - more mailing lists