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: <46390523.5010809@goop.org>
Date:	Wed, 02 May 2007 14:39:47 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Gerd Hoffmann <kraxel@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jeff Garzik <jeff@...zik.org>, patches@...-64.org,
	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for
 relocatable bzImage

H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>   
>> Hm, that's unfortunate.  How about an ELF file wrapped in some other
>> container, so that we can easily extract a properly formed ELF file?
>>
>>     
>
> Effectively the same thing as changing the magic number.  Note that the
> format for bzImage is pretty rigid, and it would be *highly* undesirable
> to muck that up.

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?

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