| Message ID | 1465627075-13683-1-git-send-email-champetier.etienne@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
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. - Felix
Hi Felix, 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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) Etienne > - Felix
On 13/06/2016 00:56, Etienne Champetier wrote: > Hi Felix, > > 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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 ideas what a short/descriptive name for the option would be ? John > Etienne > >> - Felix > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev >
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@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
Just a FYI in case you didn't see it, Ted Ts'o posted a 7-patch cluster for changing urandom that he plans to get into the next kernel Subject: PATCH-v4 0/7] random: replace urandom pool with a CRNG https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1166186.html David Lang
Hi John, Felix, 2016-06-13 13:55 GMT+02:00 John Crispin <john@phrozen.org>: > > > On 13/06/2016 00:56, Etienne Champetier wrote: >> Hi Felix, >> >> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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... 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? Etienne > > ideas what a short/descriptive name for the option would be ? > > John > > >> Etienne >> >>> - Felix >> >> _______________________________________________ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev >>
On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote: > 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 told that even cheap wear-levelling and flash chips from 4-5 years ago with even 4 MB flash that it's really non-issue (and done the math for what would be the case if wear levelling worked as claimed, on all blocks, not just currently unwritten; the real question is whether wear-levelling works as claimed, or more to the point whether there is any *hard data* that says wear levelling does *not* work as claimed, or whether persistent anecdotal stories of worn out flash are based on urban legends, or classic mis-attribution). Regards, Daniel
On 2016-06-13 22:10, Etienne Champetier wrote: > Hi John, Felix, > > 2016-06-13 13:55 GMT+02:00 John Crispin <john@phrozen.org>: >> >> >> On 13/06/2016 00:56, Etienne Champetier wrote: >>> Hi Felix, >>> >>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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
2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>> >>> >>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>> Hi Felix, >>>> >>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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
On 2016-06-14 10:13, Etienne Champetier wrote: >>> 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? I think that's reasonable. - Felix
On 14/06/16 09:13, Etienne Champetier wrote: > 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>>> >>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>> Hi Felix, >>>>> >>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@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 And I'll look at getting dnsmasq/dnssec to work with ntp hotplug as well. I'm not a quick or elegant coder ;-) >> - Felix > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
On 14/06/16 10:05, Kevin Darbyshire-Bryant wrote: > > > On 14/06/16 09:13, Etienne Champetier wrote: >> 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 > And I'll look at getting dnsmasq/dnssec to work with ntp hotplug as > well. I'm not a quick or elegant coder ;-) https://github.com/lede-project/source/pull/119 - very RFC!
On Tue, 14 Jun 2016, Etienne Champetier wrote: > 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>>> >>>> >>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>> Hi Felix, >>>>> >>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@nbd.name>: >>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote: >>>> >>>> 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? The worst thing that you can do is to use the same seed on multiple boots. David Lang
Hi David, 2016-06-14 20:21 GMT+03:00 David Lang <david@lang.hm>: > On Tue, 14 Jun 2016, Etienne Champetier wrote: > >> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>>>> >>>>> >>>>> >>>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>>> >>>>>> Hi Felix, >>>>>> >>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@nbd.name>: >>>>>>> >>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote: >>>>> >>>>> >>>>> 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? > > > The worst thing that you can do is to use the same seed on multiple boots. I agree that we should use a new seed each time, but are you suggesting that using the same seed is worse than no seed? Do you have some links to back your claim? Seeding here is just writing 512 bytes from getrandom() back into /dev/urandom, so this gets mixed with what's already available without affecting entropy estimation > > David Lang
On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote: > On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote: > >> 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 told that even cheap wear-levelling and flash chips from 4-5 years > ago with even 4 MB flash that it's really non-issue (and done the math > for what would be the case if wear levelling worked as claimed, on all > blocks, not just currently unwritten; the real question is whether > wear-levelling works as claimed, or more to the point whether there is > any *hard data* that says wear levelling does *not* work as claimed, or > whether persistent anecdotal stories of worn out flash are based on > urban legends, or classic mis-attribution). Well, we don't have a layer that will implement wear leveling in OpenWRT/LEDE do we? We use the raw flash and the filesystem, so unless the filesystem is moving directories they will be hot spots. But even in that case, aren't we talking hundreds of thousands to millions of writes before there is a problem? David Lang
Citeren David Lang <david@lang.hm>: > On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote: > >> On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote: >> >>> 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 told that even cheap wear-levelling and flash chips from 4-5 years >> ago with even 4 MB flash that it's really non-issue (and done the math >> for what would be the case if wear levelling worked as claimed, on all >> blocks, not just currently unwritten; the real question is whether >> wear-levelling works as claimed, or more to the point whether there is >> any *hard data* that says wear levelling does *not* work as claimed, or >> whether persistent anecdotal stories of worn out flash are based on >> urban legends, or classic mis-attribution). > > Well, we don't have a layer that will implement wear leveling in > OpenWRT/LEDE do we? We use the raw flash and the filesystem, so > unless the filesystem is moving directories they will be hot spots. Indeed. > But even in that case, aren't we talking hundreds of thousands to > millions of writes before there is a problem? Not really. Assuming NOR flash (which is most common in the 4-16 MB range), write endurance is usually typically something in the order of 100.000 times or more. It's the drop in retention time that worries me. See https://www.micron.com/~/media/documents/products/technical-note/nor-flash/tn1230_nor_flash_cycling_endurance_data_retention.pdf At a temperature of 55 degrees C or above, retention times can be in the order of 1 year (or less) for flash that is written a lot. You should always keep writes to a minumum (< 1000). On the other hand, if writing to flash once every boot is will be an issue, you have bigger problems to worry about. Arjen
On Tue, 14 Jun 2016, Etienne Champetier wrote: > Hi David, > > 2016-06-14 20:21 GMT+03:00 David Lang <david@lang.hm>: >> On Tue, 14 Jun 2016, Etienne Champetier wrote: >> >>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>>>>> >>>>>> >>>>>> >>>>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>>>> >>>>>>> Hi Felix, >>>>>>> >>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@nbd.name>: >>>>>>>> >>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote: >>>>>> >>>>>> >>>>>> 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? >> >> >> The worst thing that you can do is to use the same seed on multiple boots. > > I agree that we should use a new seed each time, > but are you suggesting that using the same seed is worse than no seed? I would argue that from a technical point of view that the difference between using no seed and using the same seed for a week or so at a time is so small as to be almost meaningless in practice. From a Social point of view, adding such a thing in is a net negative because it gives a false sense of security and encourages others to fall into the same trap. Doing this at first boot (once sufficiant randomness is available) so that not every device out there with the same build starts out with an identical pool, but beyond that, either do it every boot or don't bother. > Do you have some links to back your claim? google for "security theater" and you will find lots of discussion about the problems of things that people do to feel safer that end up being net negative. > Seeding here is just writing 512 bytes from getrandom() back into > /dev/urandom, so this gets mixed with what's already available without > affecting entropy estimation and even if this is written out hourly (by a system frequently rebooting), hitting a very conservative 100,000 writes would take 11 years. If you haven't been following it, it's worth going back and reading the discussion on urandom that has been taking place on the kernel mailing list over the last couple of months. There is a re-work of urandom planned to go into the next release, specifically targeting OpenWRT/LEDE type devices. David Lang
2016-06-14 21:15 GMT+03:00 David Lang <david@lang.hm>: > On Tue, 14 Jun 2016, Etienne Champetier wrote: > >> Hi David, >> >> 2016-06-14 20:21 GMT+03:00 David Lang <david@lang.hm>: >>> >>> On Tue, 14 Jun 2016, Etienne Champetier wrote: >>> >>>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd@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@phrozen.org>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Felix, >>>>>>>> >>>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd@nbd.name>: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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? >>> >>> >>> >>> The worst thing that you can do is to use the same seed on multiple >>> boots. >> >> >> I agree that we should use a new seed each time, >> but are you suggesting that using the same seed is worse than no seed? > > > I would argue that from a technical point of view that the difference > between using no seed and using the same seed for a week or so at a time is > so small as to be almost meaningless in practice. > > From a Social point of view, adding such a thing in is a net negative > because it gives a false sense of security and encourages others to fall > into the same trap. > > Doing this at first boot (once sufficiant randomness is available) so that > not every device out there with the same build starts out with an identical > pool, but beyond that, either do it every boot or don't bother. I agree that giving false sense of security should be avoided. > >> Do you have some links to back your claim? > > > google for "security theater" and you will find lots of discussion about the > problems of things that people do to feel safer that end up being net > negative. > >> Seeding here is just writing 512 bytes from getrandom() back into >> /dev/urandom, so this gets mixed with what's already available without >> affecting entropy estimation > > > and even if this is written out hourly (by a system frequently rebooting), > hitting a very conservative 100,000 writes would take 11 years. Also agree... Felix, John, is your nack on writing on every boot final? > > If you haven't been following it, it's worth going back and reading the > discussion on urandom that has been taking place on the kernel mailing list > over the last couple of months. There is a re-work of urandom planned to go > into the next release, specifically targeting OpenWRT/LEDE type devices. I just read the link you provided (thanks), not the previous discussions (i will try to read it) Etienne > > David Lang
On 14/06/2016 22:14, Etienne Champetier wrote:
> Felix, John, is your nack on writing on every boot final?
if there is an alternate way to do so then yes. as i said before, adding
a optin/out option should be possible. i always went by the rule that
writing a sector more than 1000 times should be avoided. i thin that is
called convergence and had to do with environmental temperatures. would
need to look it up and find a link. so even 2 boots/day would mean the
unit is dead after 2 years. please keep in mind that latest chips might
handle lots of writes but not everyone has a spanking new unit. lots of
people use 5-10 year old routers.
to be honest, this discussion span off topic a bit and i only marginally
followed it.
diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed new file mode 100755 index 0000000..d7c1f71 --- /dev/null +++ b/package/base-files/files/etc/init.d/urandom_seed @@ -0,0 +1,22 @@ +#!/bin/sh /etc/rc.common + +START=99 + +SEED=/etc/urandom.seed + +error_exit() { + logger -t urandom_seed "$1" + exit 1 +} + +save_seed() { + touch $SEED.tmp || error_exit "touch failed" + chown root:root $SEED.tmp || error_exit "chown failed" + chmod 600 $SEED.tmp || error_exit "chmod failed" + getrandom 512 > $SEED.tmp || error_exit "getrandom failed" + mv $SEED.tmp $SEED || error_exit "mv failed" +} + +boot() { + save_seed +} diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed new file mode 100644 index 0000000..27ff587 --- /dev/null +++ b/package/base-files/files/lib/preinit/81_urandom_seed @@ -0,0 +1,15 @@ +#!/bin/sh + +do_urandom_seed() { + S=/etc/urandom.seed + U=/dev/urandom + + [ -c $U ] || { echo "Something is wrong with $U"; return; } + [ -f $S ] || { echo "Seed file not found: $S"; return; } + [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; } + + echo "Seeding $U with $S" + cat $S > $U +} + +boot_hook_add preinit_main do_urandom_seed
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 Signed-off-by: Etienne CHAMPETIER <champetier.etienne@gmail.com> --- package/base-files/files/etc/init.d/urandom_seed | 22 ++++++++++++++++++++++ .../base-files/files/lib/preinit/81_urandom_seed | 15 +++++++++++++++ 2 files changed, 37 insertions(+) create mode 100755 package/base-files/files/etc/init.d/urandom_seed create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed