[LEDE-DEV] [PATCH] base-files: seed /dev/urandom
Kevin Darbyshire-Bryant
kevin at darbyshire-bryant.me.uk
Mon Jun 13 12:34:08 PDT 2016
On 13/06/16 12:55, John Crispin wrote:
>
> On 13/06/2016 00:56, Etienne Champetier wrote:
>> Hi Felix,
>>
>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>> This commit:
>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>> (using /lib/preinit/81_urandom_seed)
>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>> pool is initialized (using /etc/init.d/urandom_seed)
>>>>
>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>
>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>
>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>> messages in the logs, but we can now ignore them
>>>>
>>>> We could also add an urandom.seed at build time to improve first boot
>>> I'm not sure writing to flash on every single boot on every device is a
>>> good default behavior.
>>>
>> Just saw your comment, it endend up in spam ...
>>
>> Reusing the same seed multiple time is not really recommended, as it
>> means all boot with same seed are in the same state.
>> What would be an acceptable behaviour for you?
>> I could wait for ntp and then check if seed is older than X, but
>> that's way less robust.
>>
>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>
Potentially writing at every dnsmasq TERM as well, since it prefers to
maintain an up-to-date 'last known good timestamp' for comparison purposes.
> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
> lock this and the dnssec time stuff with it and default it to 0
>
> ideas what a short/descriptive name for the option would be ?
>
> John
I've a feeling that a default of '0' for dnsmasq would break the 'last
known good' time logic. The algorithm (simplistically) is "if the
current system time is BEFORE the timestamp file date, then the clock
hasn't been set so don't check DNSSEC signature timestamps thus allowing
name resolution to complete" Once the clock goes beyond 'timestamp'
then time is considered valid, DNSSEC signature timestamps are checked,
also the timestamp file mtime is updated.
The above is straightforward until sysfixtime appears on the scene,
which by default and in an attempt to be helpful (?) searches through
/etc and sets system time to the newest timestamped file...EXCLUDING
dnsmasq.time for that would be self defeating! I don't think
/etc/urandom.seed needs to be excluded from sysfixtime as the file isn't
updated on shutdown.
I'm beginning to think that the whole /etc/dnsmasq.time thing whilst a
'quick & dirty' workaround to the whole chicken'n'egg 'ntpd needs name
resolution to work irrespective of time being valid' problem was a
reasonable idea, a solution that relies on ntp raising a 'time is valid'
flag would be better. The flag could go in /tmp.
I'm really NOT a fan of using the SIGHUP signalling to dnsmasq that time
is now okay - there's too much to go wrong in terms of signalling in the
event of dnsmasq restarting for whatever reason. Much better that
dnsmasq is started without signature timestamp checking, the SIGHUP code
patched out and ntpd sets a 'time now set' flag and hard bounces
dnsmasq. dnsmasq's startup scripts can look for the flag in /tmp and if
found start in full dnssec checking mode. The myriad versions of ntpd
would need investigation as to their own 'time is ok' signalling abilities.
Apologies, this has gone a bit off topic but I think relevant.
Kevin
More information about the Lede-dev
mailing list