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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 05 Jan 2009 11:36:12 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alain Knaff <alain@...ff.lu>
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

Alain Knaff wrote:
> 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.

Yes.  That is a deliberate tradeoff in our culture.  It's hardly a 
secret, either.

> 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").

Well, I think the right thing to do at this stage is to simply compress 
the initramfs with the preferred compression method (and if no 
compression method is provided, with none.)  This can be relatively 
simply done with a script, I think.

At least that way the whole image is compressed using the preferred 
compression format, and since all the relevant compressors have methods 
of dealing reasonably with uncompressable chunks we should be okay.

Doing the "free as you go" thing is definitely something I would like to 
see, as well as supporting initramfs in high memory.  I have looked at 
it a few times, however, it is a nontrivial modification and I haven't 
personally devoted the time to dealing with it.  I really don't think we 
want to entangle this issue with the compression patch.

	-hpa

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