fs/cpio: drop static random-seed
PATCH 1/1 fs/cpio: drop static random-seed
Initializing the kernel entropy pool in initramfs from a seed file that never changes doesn't make much sense. Not initializing the entropy pool at all is better than initializing it from a known seed.
--- fs/cpio/cpio.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/cpio/cpio.mk +2 -1
@@ -28,7 +28,8 @@ endif # BR2_ROOTFS_DEVICE_CREATION_STATIC ROOTFS_CPIO_PRE_GEN_HOOKS += ROOTFS_CPIO_ADD_INIT define ROOTFS_CPIO_CMD - cd $(TARGET_DIR) && find . | cpio --quiet -o -H newc > $@ + cd $(TARGET_DIR) && find . \! -path ./etc/random-seed \ + | cpio --quiet -o -H newc > $@ endef $(BINARIES_DIR)/rootfs.cpio.uboot: $(BINARIES_DIR)/rootfs.cpio host-uboot-tools
Signature · 1 line
2.1.4
PATCH 1/1 fs/cpio: drop static random-seed
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Baruch" == Baruch Siach <[email protected]> writes:
Initializing the kernel entropy pool in initramfs from a seed file that never changes doesn't make much sense. Not initializing the entropy pool at all is better than initializing it from a known seed.
Signed-off-by Baruch Siach <[email protected]>
I agree, but why don't we simply drop our static /etc/random-seed from the default skeleton instead?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 fs/cpio: drop static random-seed
Hi Peter,
Quoted 10 lines · Peter Korsgaard
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Baruch" == Baruch Siach <[email protected]> writes:
Initializing the kernel entropy pool in initramfs from a seed file that never changes doesn't make much sense. Not initializing the entropy pool at all is better than initializing it from a known seed.
Signed-off-by Baruch Siach <[email protected]>I agree, but why don't we simply drop our static
/etc/random-seedfrom the default skeleton instead?
Good idea. /etc/random-seed is less harmful on persistent filesystems, as it only affects the first boot. But it probably doesn't do any good either.
In addition to that I think it would also be better not to use /etc/random-seed when the filesystem is read-only, even when that file exists. Currently /etc/init.d/S20urandom reads /etc/random-seed from a read-only filesystem, but doesn't write it, which seems just wrong.
What do you thing?
I'll send patches if everybody agree on the plan.
baruch
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -PATCH 1/1 fs/cpio: drop static random-seed
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Baruch" == Baruch Siach <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 2 lines
I agree, but why don't we simply drop our static
/etc/random-seedfrom the default skeleton instead?Good idea.
/etc/random-seedis less harmful on persistent filesystems, as it only affects the first boot. But it probably doesn't do any good either.
Yes, but plenty of people use a readonly /etc, so they have the same issue.
Quoted 6 lines
In addition to that I think it would also be better not to use
/etc/random-seedwhen the filesystem is read-only, even when that file exists. Currently/etc/init.d/S20urandomreads/etc/random-seedfrom a read-only filesystem, but doesn't write it, which seems just wrong.What do you thing?
It was discussed recently:
http://lists.busybox.net/pipermail/buildroot/2015-March/121708.html
I think we should just remove the hardcoded seed file. If people have a persistent RW /etc then S20urandom handles it, and otherwise it doesn't do anything.
You can argue if it makes sense to update /etc/random-seed directly in the start phase of the init script (as the system will not have a lot of interesting entropy), but most systems probably don't get shut down nicely, so the stop action never runs.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard