On Tue, Feb 04, 2014 at 05:39:57PM +0100, Hannes Frederic Sowa wrote:
> 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
> 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).
>
> Have you looked into adding compiler barriers into relevant places in the
> loops to stop the compiler from optimizing and spill out the values from the
> registers to their memory locations?
Quick follow-up:
Maybe you can get some ideas how to stop the compiler from optimizing code
from commit fe8c8a126806fe ("crypto: more robust crypto_memneq"). Maybe also
volatile could be helpful and OPTIMIZER_HIDE_VAR seems to be a good candidate
to use here, too.
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
