linux-kernel - Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

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: <m1tzuuv24z.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 03 May 2007 00:42:52 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	vgoyal@...ibm.com
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Gerd Hoffmann <kraxel@...hat.com>,
	Jeff Garzik <jeff@...zik.org>, patches@...-64.org,
	linux-kernel@...r.kernel.org,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Vivek Goyal <vgoyal@...ibm.com> writes:

> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> > 
>> > So the bzImage structure is currently:
>> > 
>> >    1. old-style boot sector
>> >    2. old-style boot info, followed by 0xaa55 at the end of the sector
>> >    3. the HdrS boot param block
>> >    4. setup.S boot code
>> >    5. the self-decompressing kernel
>> > 
>> > If we make 5 actually an ELF file, containing properly formed Ehdr,
>> > Phdrs (for all the mappings required), and the actual kernel
>> > decompressor, relocator and compressed kernel data, then it would be
>> > easy for the Xen domain builder to find that and use it as a basis for
>> > loading.  I think it would just require the bzImage boot param block to
>> > contain an offset of the start of the ELF file.  The contents of the ELF
>> > file would be in a form where the normal boot code could just jump over
>> > the ELF headers, directly into the segment data itself.
>> > 
>> > ie:
>> > 
>> >    1. old-style boot sector
>> >    2. old-style boot info, followed by 0xaa55 at the end of the sector
>> >    3. the HdrS boot param block
>> >    4. setup.S boot code (jumps directly into 5.3)
>> >    5. 32-bit self-decompressing kernel:
>> >          1. Ehdr
>> >          2. Phdrs for all necessary mappings
>> >          3. decompressor/relocator .text
>> >          4. compressed kernel data
>> > 
>> > Does that sound reasonable?
>> > 
>> 
>> I don't know if that would break any programs that are currently
>> bypassing the setup.

I think everything will break, unless we make 5.1 and 5.2 
into 4.2 and 4.3.  In the above design.

> I think kexec bzImage loader will break. It bypasses the setup code and
> directly jumps to the code present after setup sectors(decompressor).

Quite likely.    The boot sector except for a handful of bytes actually
goes unused so we can put extra header information there, I actually
have patches for placing an ELF header there.

If we wanted to do an ELF header in the middle we would have to put
it at the end of the setup sectors rather then the beginning of the
raw protected mode kernel image.

>> The existing setup protocol definitely allows
>> invoking an entry point which isn't 0x100000 (rather, the 32-bit
>> entrypoint is defined by code32_start); I'm not sure how Eric's
>> relocatable kernel patches (2.05 protocol) affect that, mostly because I
>> haven't seen any boot loaders which actually use it so I can't comment
>> on what their code looks like.
>
> With relocatable patches, if a boot loader decides to load protected mode
> component at non-1MB address, then it shall have to modify code32_start to
> reflect the new location of protected mode code.

Yes.  And this aspect of the relocatable kernel is all Vivek.

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/