On Fri, Sep 27, 2019 at 6:57 AM Lennart Poettering <mzxreary@xxxxxxxxxxx> wrote:
>
> Doing the random seed in the boot loader is nice for two reasons:
>
> 1. It runs very very early, so that the OS can come up with fully
> initialized entropy right from the beginning.
Oh, that part I love.
But I don't believe in your second case:
> 2. The boot loader generally has found some disk to read the kernel from,
> i.e. has a place where stuff can be stored and which can be updated
> (most modern boot loaders can write to disk these days, and so can
> EFI). Thus, it can derive a new random seed from a stored seed on disk
> and pass it to the OS *AND* update it right away on disk ensuring that
> it is never reused again.
No. This is absolutely no different at all from user space doing it
early with a file.
All the same "golden image" issues exist, and in general the less the
boot loader writes to disk, the better.
Plus it doesn't actually work anyway in the one situation where people
_really_ want it - embedded devices, where the kernel image is quite
possibly in read-only flash that needs major setup for updates.
PLUS.
Your "it can update it right away on disk" is just crazy talk. With
WHAT? It has no randomness to play with, and it doesn't have time to
do jitter entropy stuff.
So all it can do is a really bad job at taking the previous random
seed, doing some transformation on it, and add a little bit of
whatever system randomness it can find. None of which is any better
than what the kernel can do.
End result: you'd need to have the kernel update whatever bootloader
data later on, and I'm not seeing that happening. Afaik the current
bootloader interface has no way to specify how to update it when you
actually have better randomness.
> NVRAM backing EFI vars sucks. Nothing you want to update on every
> cycle. It's OK to update during OS installation, but during every
> single boot? I'd rather not.
I do agree that EFI nvram isn't wonderful, but hopefully nonvolatile
storage is improving, and it's conceptually the right thing.
Linus
