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

[Etienne Champetier]

2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
> 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.

Ok, let's find a middle ground :)
What about saving a seed if there is none (on boot), and then using an
ntp hotplug (stratum event) and save a new seed if older than say 1
week?

Etienne

>
> - Felix