linux-kernel - Re: [PATCH 0/5] Boot protocol changes

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:	Tue, 02 Oct 2007 16:53:06 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Vivek Goyal <vgoyal@...ibm.com>, lguest <lguest@...abs.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 0/5] Boot protocol changes

Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
>> Hi all,
>>
>> 	Jeremy had some boot changes for bzImages, but buried in there was an
>> update to the boot protocol to support Xen and lguest (and kvm-lite).
>> I've copied those fairly simple patches, and if HPA is happy I'd like to
>> push them for 2.6.24 (after correcting for the Great Arch Merge of
>> course).
> 
> Ah, good.  I was thinking about reviving this work.  The main problem is
> that sticking an ELF header at the 1 meg mark (the address of the
> bzImage "payload") breaks 32-bit bootloaders which think they can just
> jump to 32-bit code there.  I started a conversation with Eric at KS
> about it, but we didn't reach any conclusions.
> 
> This series looks like a good start for Xen, but we still need to work
> out where to stash the metadata which normally lives in ELF notes.  
> Using ELF is convenient for Xen because it lets a large chunk of domain
> builder code be reused; on the other hand, loading a plain bzImage is
> pretty simple, so maybe it isn't such a big deal.
> 
> HPA, Eric: if we don't go the "embed ELF" path, where's a good
> backwards-compatible place to stash the note data?  If we do go with
> "embed ELF", how should we go about doing it?  Arrange to put the ELF
> headers before the 1M mark?
> 

This sounds like another good reason to do the ELF image as the 
postcompression image.  The interface to the embedded compression 
routine is then unchanged, and we get the "full vmlinux" with any notes 
that belongs there.

I'll try to get an implementation of that done -- it really shouldn't be 
very hard.

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