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:	Mon, 23 Dec 2013 20:08:15 +0530 (IST)
From:	P J P <ppandit@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jan Beulich <JBeulich@...e.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Broken initrd compression settings in 3.13

   Hi,

+-- On Fri, 20 Dec 2013, Linus Torvalds wrote --+
| So commit 1bf49dd4be0b ("./Makefile: export initial ramdisk
| compression config option") seems to be totally broken.
| 
| And I'm not saying that because Jan fixed a make-3.80 incompatibility
| in commit 7ac181568342 ("fix build with make 3.80")
| 
| I'm saying that because it sets and exports the INITRD_COMPRESS
| environment variable completely incorrectly, as far as I can tell.
| 
| And it looks like nobody noticed, because apparently dracut didn't use
| to care about that INITRD_COMPRESS environment variable at all. But as
| of a F20 update yesterday, apparently dracut actually does care, and
| as a result nothing actually works.

  This issue was indeed noticed earlier and is fixed in commit '9ba4bcb645' 
which defaults to '.gz' compression when all CONFIG_RD_* options are set.

  -> https://lkml.org/lkml/2013/10/30/535

The issue occurs due the order in which variables are examined in 
usr/Makefile.

| That setting is f*cking moronic. It sets INITRD_COMPRESS to 'lz4' if
| RD_LZ4 is set. But RD_LZ4 is *always* set (unless you go into some
| expert settings), so basically what that commit does is to always set
| INITRD_COMPRESS to lz4.

  No, it does not! It would set INITRD_COMPRESS=lz4 when *only* CONFIG_RD_LZ4 
option is set and none other. That would be moronic thing to do. But that is 
almost impossible to happen via a distro kernel config because even if you 
could build a kernel with only CONFIG_RD_LZ4, it would not boot because the 
de-compressor in 'lib/decompress_unlz4.c' is broken since they changed the LZ4 
file format

 -> http://fastcompression.blogspot.fr/2013/04/lz4-streaming-format-final.html

|  (b) there's no way to select the compression level (unlike the
| INITRAMFS_COMPRESSION thing that actually has a choice)

   Ummn...?

|  (c) even if you *do* have lz4, it doesn't actually work, because
| while that causes the new F20 dracut to compress the initramfs with
| lz4, the end result is completely broken, because the F20 "lsinitrd"
| scripts don't understand the end result, so now the whole kernel
| install fails.

   Strange! I'm running kernel-3.12.0 which seems to have commit 
'1bf49dd4be0b' which exports INITRD_COMPRESS, but not commit '9ba4bcb645' 
which fixes the usr/Makefile. For the test I enabled all CONFIG_RD_ options

===
...
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y

...
# make install
/usr/src/kernels/linux-3.12/arch/x86/boot/install.sh: INITRD_COMPRESS: bzip2
/sbin/dracut: compress: bzip2 -9 (bzip2)
# 
# file /boot/initramfs-3.12.0.img 
/boot/initramfs-3.12.0.img: bzip2 compressed data, block size = 900k
# 
===

So, the final initramfs-3.12.0 is still .bzip2 compressed, which lsinitrd(1) 
does understand. Yet, it won't boot because the lz4 de-compressor is broken. I 
tried to look into it briefly to create a fix, but then got occupied with 
other work and am yet to get back to it. :(

| I'm going to remove that export of INITRD_COMPRESS, since right now
| that value is broken and useless. No way does it make sense to
| mindlessly default to a compressor that most people don't have, and
| that doesn't work with most tools.

  Or include the patch '9ba4bcb645' which fixes this issue. I see it already 
merged actually.

--
Prasad J Pandit / Red Hat Security Response Team
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ