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: <m1lkq7txz0.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 02 Aug 2006 01:09:55 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Magnus Damm" <magnus.damm@...il.com>
Cc:	fastboot@...l.org, linux-kernel@...r.kernel.org,
	Horms <horms@...ge.net.au>,
	"Jan Kratochvil" <lace@...kratochvil.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Vivek Goyal" <vgoyal@...ibm.com>, "Linda Wang" <lwang@...hat.com>
Subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages

"Magnus Damm" <magnus.damm@...il.com> writes:

> On 8/1/06, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> The problem:
>>
>> We can't always run the kernel at 1MB or 2MB, and so people who need
>> different addresses must build multiple kernels.  The bzImage format
>> can't even represent loading a kernel at other than it's default address.
>> With kexec on panic now starting to be used by distros having a kernel
>> not running at the default load address is starting to become common.
>>
>> The goal of this patch series is to build kernels that are relocatable
>> at run time, and to extend the bzImage format to make it capable of
>> expressing a relocatable kernel.
>
> Nice work. I'd really like to see support for relocatable kernels in
> mainline (and kexec-tools!).

kexec-tools already have initial support for ELF ET_DYN executables.
Vivek posted a fix a day two ago so I expect that the support
should be working.

> Eric, could you please list the advantages of your run-time relocation
> code over my incomplete relocate-in-userspace prototype posted to
> fastboot a few weeks ago?

If you watch an architecture evolve one thing you will notice is that
the kinds of relocations keep growing.  An ever growing list of things
to for the bootloader to do is a pain.  Especially when bootloaders
generally need to be as simple and as fixed as possible because bootloaders
are not something you generally want to update.

Beyond that if you look at head.S the code to process the relocations 
(after I have finished post processing them at build time) is 9 instructions.
Which is absolutely trivial, at least for now.

By keeping the bzImage processing the relocations we have kept the
bootloader/kernel interface simple.

> One thing I know for sure is that your implementation supports bzImage
> while my only supports relocation of vmlinux files. Are there any
> other uses for relocatable bzImage except kdump?

I can't think of any volume users.  A hypervisor that would actually report
the real physical addresses would be a candidate.  It's a general purpose
facility so if it is interesting users will show up.  Static
relocation has already found another use on x86_64.

There are definitely users of an ELF bzImage beyond the kdump case.
Anything that doesn't have a traditional 16bit BIOS on it.  LinuxBIOS,
and Xen, and some others.

Not having to keep track of anything but your bzImage to boot is also
a serious advantage.  It's the one binary to rule them all. :)

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/