linux-kernel - Re: [RFC] ELF Relocatable x86 and x86

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]

Message-ID: <m17j1nobla.fsf@ebiederm.dsl.xmission.com>
Date:	Sat, 05 Aug 2006 02:01:21 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dave Jones <davej@...hat.com>, vgoyal@...ibm.com,
	fastboot@...l.org, linux-kernel@...r.kernel.org,
	Horms <horms@...ge.net.au>,
	Jan Kratochvil <lace@...kratochvil.net>,
	Magnus Damm <magnus.damm@...il.com>,
	Linda Wang <lwang@...hat.com>
Subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages

"H. Peter Anvin" <hpa@...or.com> writes:

> Dave Jones wrote:
>> On Fri, Aug 04, 2006 at 05:14:37PM -0600, Eric W. Biederman wrote:
>>  > I guess the practical question is do people see a real performance benefit
>>  > when loading the kernel at 4MB?
>> Linus claimed lmbench saw some huge wins. Others showed that for eg,
>> a kernel compile took the same amount of time, so take from that what you
> will..

But Linus wasn't comparing the same version of the kernel.  So it was
a bit unknown.  Having someone reproduce those lm_bench numbers on the
exact same kernel would be interesting.

>> > Possibly the right solution is to do like I did on x86_64 and simply remove
>> > CONFIG_PHYSICAL_START, and always place the kernel at 4MB, or something like
>>  > that.
>> > > The practical question is what to do to keep the complexity from spinning
>>  > out of control.  Removing CONFIG_PHYSICAL_START would seriously help with
>>  > that.
>> Given the two primary uses of that option right now are a) the aforementioned
>> perf win and b) building kexec kernels, I doubt anyone would miss it once
>> we go relocatable ;-)
>>
>
> We DO want the performance gain with a conventional bootloader.  The perf win is
> about the location of the uncompressed kernel, not the compressed kernel.

Agreed.

We also need a way to boot a kernel on an old machine with limited memory.
Possibly we would only support this if PSE is not supported, which old machines
don't support.

The complication that the decompressor must relocation the image for
supporting old bootloaders is challenging in the context or a truly relocatable
kernel, where we run at the address the bootloader put us.

The basic other concern is how flexible do we need to be with respect to relocation.

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