[systemd-devel] Antw: Re: Antw: [EXT] Re: Journal message timestamps

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Mon Sep 7 07:55:18 UTC 2020


>>> Lennart Poettering <lennart at poettering.net> schrieb am 04.09.2020 um 18:13
in
Nachricht <20200904161306.GP267847 at gardel-login>:
> On Fr, 28.08.20 10:20, Ulrich Windl (Ulrich.Windl at rz.uni‑regensburg.de)
wrote:
> 
>> The code in the kernel relies on feeding the random pool probably before
>> getting the first UUID (but obviously too late for boot_id):
> 
> The boot ID code is in the kernel. It knows better than userspace when
> the entropy pool is initialized.
> 
>>  *      echo "Initializing random number generator..."
>>  *      random_seed=/var/run/random‑seed
>>  *      # Carry a random seed from start‑up to start‑up
>>  *      # Load and then save the whole entropy pool
>>  *      if [ ‑f $random_seed ]; then
>>  *              cat $random_seed >/dev/urandom
>>  *      else
>>  *              touch $random_seed
>>  *      fi
>>  *      chmod 600 $random_seed
>>  *      dd if=/dev/urandom of=$random_seed count=1 bs=512
> 
> systemd has "systemd‑random‑seed.service" which something similar, but
> a bit smarter. It's not as useful as people might assume though, since
> it has to wait that /var is writable, since we should not use the seed
> data unless we can make sure it's not going to be reused on next boot
> (because coming up with the very same seed on every boot is the
> opposite of random). Thus we need to invalidate the random seed first,
> then upload it to the kernel, then write a new random seed to disk.
> 
> The boot ID is generated very early on during boot, by the kernel
> internally long before /var becomes writable. Hence the entropy for it
> needs to come from somewhere else, and the kernel needs to make sure
> to generate it only after the entropy pool in the kernel is filled.
> 
>> What systemd might do is: Save the last boot_id. If the current boot_id is

> the
>> same as the last one during boot, either do:
> 
> No, we rely on the kernel to work correctly. The same way as
> /dev/urandom is kernel API /proc/sys/kernel/random/boot_id is kernel
> API and we should rely on it to work and if it doesn't then it needs
> to be fixed in the kernel.

Lennart,

you seem to miss my point:
I tried to explain that any user-supplied randomness will arrive too late for
boot_id. So sources that may contribute are the RTC and the boot device and
maybe some interrupts. But if there is not RTC, no loaded NIC driver and the
boot disk in on flash, there's likely no randomness.
A crude workaound I could think of is top provide "randomness" via a kernel
parameter: On shutdown you would patch the GRUB menu to receive a new
randomness value...

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin





More information about the systemd-devel mailing list