linux-kernel - Re: tip: bzip2/lzma now in tip:x86/setup-lzma

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]

Message-ID: <4962580B.2080806@knaff.lu>
Date:	Mon, 05 Jan 2009 19:57:15 +0100
From:	Alain Knaff <alain@...ff.lu>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: tip: bzip2/lzma now in tip:x86/setup-lzma

H. Peter Anvin wrote:
> Alain Knaff wrote:
>>
>> Yes, now I remember. We had that subject of compressed builtin
>> initramfs' a while ago. Back then, I proposed to just leave it
>> uncompressed (considering that it is part of the kernel, which is
>> compressed anyways)... but that apparently caused problems for some
>> people who liked to store huge amount in there, due to some artifacts
>> about how initramfs initialization works.
>>
>> Well, I'd think in that case, the most expedient method would be to have
>> CONFIG_RD_GZIP always defined.
>>
> 
> Expedient, perhaps, but it's not the right solution.  The same people
> who want a large builtin initramfs are generally the ones that care
> about image size.  If we gzip the internal image, it will in fact
> nullify the benefit of using a better compressor for the kernel image in
> general, since the gzipped portion of the image will hardly compress at
> all.
> 
>     -hpa

Exactly the reason why in one of my first versions I wanted to do away
with that feature.... until you pointed out that it was actually using
more *memory* when not compressed, because of the way the buffer cache
works when the initramfs is put into place (it is not freed "as we go",
but only at the very end, so at one point in time there will be 2 copies
which will of course be larger when they're both uncompressed).

I'm getting the impression that again, anybody wanting to propose an
enhancement must solve _all_ pre-existing problems in that area... While
this certainly leads to better code once a patch does make it, it will
certainly discourage many.

Maybe we can separate both issues, and tackle the initramfs case
entirely separately (maybe by proving a buffer cache enhancement that
allows to free initramfs' memory "as we go").

Regards,

Alain

--
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/