Re: [PATCH,RFC] random: collect cpu randomness

[Thorsten Glaser]

Theodore Ts'o dixit:

>I really like Jvrn's tests doing repeated boot testing and observing
>on a SMP system, the slab allocation pattern is quite deterministic.
>So even though the numbers might *look* random, an attacker with deep
>knowledge of how the kernel was compiled and what memory allocations

For this reason, we pre-initialise (one of) the RNG during kernel
compile time, using host randomness, in MirBSD. Weâre also considering
pushing some additional seed using the bootloader, that can be mixed
in very very early. As an added benefit, everything in the kernel can
call arc4random(), arc4random_buf() and arc4random_uniform() without
worrying about initialisation, at all times. (This is mostly for the
places where it replaced random(), or which explicitly waited for the
regular RNG initialisation to be done, or which reseeded after that.)

In GNU/Linux, this could work like, GRUB will offer the contents of
/boot/grub/randseed.bin to the Linux kernel, which will add it into
the pool using the normal mechanisms, and (very?) early userspace
will then recreate that file (to prevent seed reuse, just like the
normal /var/db/host.random or /var/lib/urandom/random-seed processing
is done). Downside: write access to the boot medium needed. (No GRUB
modification needed, this could be passed as âfaux kernel moduleâ.)
Upside: this is way earlier than anything user space can do, and
e.g. early enough to affect things like kernel memory management.

bye,
//mirabilos
-- 
<Natureshadow> Ach, mach doch was du willst, du hast doch eh immer Recht!
<mirabilos> jupp ~/.etc/sigâââ
<Natureshadow> unfaÃbarâ
<Natureshadow> Mit Eszett sogar, unfaÃbar!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/