linux-kernel - better switch back to panic on initramfs.c/populate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 24 Oct 2016 15:10:34 +0200
From:   Dennis Luehring <dl.soluz@....net>
To:     linux-kernel@...r.kernel.org
Subject: better switch back to panic on initramfs.c/populate_rootfs errors?

im building initrd/initramfs cpios for serveral qemu platforms and 
stumbled over inconsistent rootfs after kernel load
using vanilla kernel 4.8.4(and older), bash 4.4, core-utils/linux-utils 
build with gcc 6.1 under Ubuntu 16.04.1 x64 (gcc 5.4)

using a big(~370MB) initrd.cpio with not enough ram (1GB) in qemu i get 
this kernel message
"Initramfs unpacking failed: write error"
that sometimes led to missing files in my rootfs (thanks to "Richard 
Henderson"(DEC-Alpha maintainer) who directed me to the kernel log 
message - after searching for hours why some executables don't work 
after kernel load)

using a small(~14MB) initrd.cpio with just a staticaly linked c based 
init for the kernel also with 1GB ram gives me this kernel message:
"Initramfs unpacking failed: junk in compressed archive"

both initrd.cpios are created with cpio (version 2.11)
"find . | cpio -H newc -o initrd.cpio"

why do the kernel not panic if not able to populate the roofs consistently?

related to the panic i've found this commit (from 2009-01-14) that 
allows inconsistent rootfs
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/init/initramfs.c?id=73310a169aebe257efdd35a763cce1c7658f40c9
is that still a good idea/practise? to have initramfs recovery seems to 
be a rare case and a simple panic would help much better in many other 
common situations -
or are the errors comming from unpack_to_rootfs() are currently not 
always errors but sometimes warnings where panic would be the wrong 
action to take?

i don't know if both messages telling me that something bad happend and 
i need to fix it first or is the second just a warning?
"Initramfs unpacking failed: write error"
"Initramfs unpacking failed: junk in compressed archive"

please direct me to the correct mailinglist (or person) that could 
answer this questions if im wrong here

thx