Re: The policy on initramfs decompression failure

[Bodo Eggert]

On Wed, 14 Jan 2009, Ingo Molnar wrote:
> * Bodo Eggert <7eggert@xxxxxx> wrote:

> > If the initrd is not decompressed successfully, [...]
> 
> No, that's not the issue - i think hpa's description was misleading in 
> that respect.
> 
> This is not some sort of corruption. I have hit this pointless panic 
> during testing: there was nothing wrong with either the initrd or the 
> system, the bzImage simply did not include the right decompressor .config 
> option to even read the initrd.

A unknown-compressed initrd is as good or as bad as a corrupted rd.
The kernel can't decide if it's got /dev/random or e.g. a RAR archive.
Therefore it must and should behave the same.

> The analogue is if i booted a kernel with CONFIG_MODULES disabled. I do it 
> all the time, it always worked without problems and the initrd with 
> modules in it cannot be interpreted in any sane way CONFIG_MODULES - still 
> it works just fine because the initrd is uninteresting as far as the 
> modules go.

> So basically now the kernel has regressed in its bzImage utility: "oh, i 
> dont have a decompressor for the initrd. PANIC!". And that is a step 
> backwards. Unless you use bzImage i dont think you can really appreciate 
> this argument.

If there is no initrd, you won't get a panic. If you use a gzip initrd
with a bz2-only kernel what do you expect? What do you expect if you
say "root=/dev/internal-disk", but /dev/usb/attacker's-USB-stick is
currently the only working alternative?

I think having a kernel parameter ist the right thing, since it
won't decrease security, it gives everything you want and it allows
you to skip even "good" initrds if they turn out not to be good.

> I would not mind a warning message though, that bit makes sense.

"Warning, I'm starting a setup which you didn't intend to start
 at all! Muahahahaha, good luck!"
-- 
Interchangeable parts aren't.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/