Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: The policy on initramfs decompression failure | Date | Wed, 14 Jan 2009 00:42:17 +0100 |
| |
H. Peter Anvin <hpa@zytor.com> wrote:
[initramfs decryption failed]
> 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.
If the initrd is not decompressed successfully, and if it's not there for fun, the system boot will be most likely fubar, and at worst a wrong system or a less secured configuration may be started. Therefore I'd create a kernel option. Possible values would be e.g. [*panic,continue] or [*auto|required|optional|ignore], with:
panic, continue: As expected auto: If there is an initrd, it's required, otherwise it's ignored required: Panic if the initrd did not exist or was not unpacked correctly optional: Like continue ignore: Don't load the initrd *: Default value
I currently don't know how to name the option.
| |