[Buildroot] [PATCH] fs/cpio: drop static random-seed

[Buildroot] [PATCH] fs/cpio: drop static random-seed

[Baruch Siach]

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 <baruch@tkos.co.il>
---
 fs/cpio/cpio.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/cpio/cpio.mk b/fs/cpio/cpio.mk
index e82167e512dc..fa3cde64838e 100644
--- a/fs/cpio/cpio.mk
+++ b/fs/cpio/cpio.mk
@@ -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
-- 
2.1.4

[Buildroot] [PATCH] fs/cpio: drop static random-seed

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> 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 <baruch@tkos.co.il>

I agree, but why don't we simply drop our static /etc/random-seed from
the default skeleton instead?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] fs/cpio: drop static random-seed

[Baruch Siach]

Hi Peter,

On Tue, Jul 07, 2015 at 01:10:21PM +0200, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> 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 <baruch@tkos.co.il>
> 
> I agree, but why don't we simply drop our static /etc/random-seed from
> 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

-- 
     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 -

[Buildroot] [PATCH] fs/cpio: drop static random-seed

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

>> I agree, but why don't we simply drop our static /etc/random-seed from
 >> 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.

Yes, but plenty of people use a readonly /etc, so they have the same
issue.

> 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?

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.

-- 
Venlig hilsen,
Peter Korsgaard