linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2009 16:19:39 +0100 (CET)
From:	Bodo Eggert <7eggert@....de>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Bodo Eggert <7eggert@....de>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Al Viro <viro@....linux.org.uk>, Alain Knaff <alain@...ff.lu>
Subject: Re: The policy on initramfs decompression failure

On Wed, 14 Jan 2009, Ingo Molnar wrote:
> * Bodo Eggert <7eggert@....de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/