linux-kernel - The policy on initramfs decompression failure

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>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Jan 2009 14:38:49 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Al Viro <viro@....linux.org.uk>, Alain Knaff <alain@...ff.lu>
Subject: The policy on initramfs decompression failure

As part of the multi-compression-formats patch, the issue has come up as 
to what is the preferred policy is on initramfs decompression failure, 
due to either corruption or due to the use of a compression format which 
the kernel does not support.

I had personally assumed the proper policy would be to panic, since it 
is unlikely to mean the system can be booted.  However, Ingo brought up 
the case where the initramfs is auxilliary to being able to boot the 
full system, for example the initramfs supplied is primarily a data 
carrier, and either the builtin initramfs or the kernel itself is 
sufficient to boot.

By this argument, we should change initramfs decoding failure to a 
KERN_CRIT message, and in the (presumably most common) case that it does 
not suffice to boot the system, we will get a panic in short order as 
the system is unable to find init.

This argument seems to mostly hold water, but it does implement a policy 
change over the current code.  Furthermore, it does make me concerned 
that a *partial* decoding failure (such as can be caused by a corrupt 
image, or, say, a gzipped image concatenated to a bzip2 image, with the 
kernel only supporting bzip2) could cause a booted-but-dysfunctional 
system, which is in many configurations a worse failure mode than a panic.

Hence I would like to solicit opinions about what the policy should be.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/