[LEDE-DEV] [PATCH] base-files: seed /dev/urandom

[Felix Fietkau]

On 2016-06-13 22:10, Etienne Champetier wrote:
> Hi John, Felix,
> 
> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>
>>
>> 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)
>>>
>>
>> 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
> 
> Security can't be opt in !
> When you see "random: ubus urandom read with 4 bits of entropy
> available" let's hope it's not security sensitive, because 2^4 will
> not take a lot of time to bruteforce...
First of all, the kernel entropy estimation is *really* pessimistic, so
there will be a lot more random bits at this point than just 4.

> Before we try to minimize writes, how much writes are we talking about?
> my openwrt routers have multiple months of uptime, and even if we get
> down to 1 week, that gets us to 53 writes a year.
> How much writes can a flash handle these days?
I'm more concerned about the worst case than the average case here.
There are people that do a forced reboot every day (as a stability
workaround), or only power up their devices during specific times of the
day (multiple reboots per day). This can easily add up to bigger numbers.

Also, adding something like this makes other people want to add even
more stuff that writes to flash on every boot, as you've so clearly
demonstrated by pointing out that this behavior are already done for
dnssec/dnsmasq.

- Felix