Re: Linux 5.3-rc8

[Eric W. Biederman]

Lennart Poettering <mzxreary@xxxxxxxxxxx> writes:

> On Di, 17.09.19 09:23, Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx) wrote:
>
>> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering <mzxreary@xxxxxxxxxxx> wrote:
>> >
>> > Here's what I'd propose:
>>
>> So I think this is ok, but I have another proposal. Before I post that
>> one, though, I just wanted to point out:
>>
>> > 1) Add GRND_INSECURE to get those users of getrandom() who do not need
>> >    high quality entropy off its use (systemd has uses for this, for
>> >    seeding hash tables for example), thus reducing the places where
>> >    things might block.
>>
>> I really think that trhe logic should be the other way around.
>>
>> The getrandom() users that don't need high quality entropy are the
>> ones that don't really think about this, and so _they_ shouldn't be
>> the ones that have to explicitly state anything. To those users,
>> "random is random". By definition they don't much care, and quite
>> possibly they don't even know what "entropy" really means in that
>> context.
>
> So I think people nowadays prefer getrandom() over /dev/urandom
> primarily because of the noisy logging the kernel does when you use
> the latter on a non-initialized pool. If that'd be dropped then I am
> pretty sure that the porting from /dev/urandom to getrandom() you see
> in various projects (such as gdm/x11) would probably not take place.
>
> In fact, speaking for systemd: the noisy logging in the kernel is the
> primary (actually: only) reason that we prefer using RDRAND (if
> available) over /dev/urandom if we need "medium quality" random
> numbers, for example to seed hash tables and such. If the log message
> wasn't there we wouldn't be tempted to bother with RDRAND and would
> just use /dev/urandom like we used to for that.
>
>> > 2) Add a kernel log message if a getrandom(0) client hung for 15s or
>> >    more, explaining the situation briefly, but not otherwise changing
>> >    behaviour.
>>
>> The problem is that when you have some graphical boot, you'll not even
>> see the kernel messages ;(
>
> Well, but as mentioned, there's infrastructure for this, that's why I
> suggested changing systemd-random-seed.service.
>
> We can make boot hang in "sane", discoverable way.
>
> The reason why I think this should also be logged by the kernel since
> people use netconsole and pstore and whatnot and they should see this
> there. If systemd with its infrastructure brings this to screen via
> plymouth then this wouldn't help people who debug much more low-level.
>
> (I mean, there have been requests to add a logic to systemd that
> refuses booting â or delays it â if the system has a battery and it is
> nearly empty. I am pretty sure adding a cleanm discoverable concept of
> "uh, i can't boot for a good reason which is this" wouldn't be the
> worst of ideas)

As I understand it the deep problem is that sometimes we have not
observed enough random activity early in boot.

The cheap solution appears to be copying a random seed from a previous
boot, and I think that will take care of many many cases, and has
already been implemented.  Which reduces this to a system first
boot issue.

So for first system boot can we take some special actions to make
it possible to see randomness sooner.  An unconditional filesystem check
of the filesystem perhaps.  Something that will initiate disk activity
or other hardware activity that will generate interrupts and allow
us to capture randomness.

For many systems we could even have the installer capture some random
data as a final stage of the installation, and use that to seed
randomness on the first boot.

Somewhere in installing the random seed we need to be careful about
people just copying disk images from one system to another, and a
replicated seed probably can not be considered very random.

My sense is that by copying a random seed from one boot to the next
and by initiating system activity to hurry along the process of
having enough randomness we can have systems where we can almost
always have good random numbers available.

And if we almost always have good random numbers available we won't
have to worry about people getting this wrong.

Am I wrong or can we just solve random number availablity is practically
all cases?

Eric