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
| ||
|
Message-ID: <4702E5C0.5040606@zytor.com> Date: Tue, 02 Oct 2007 17:43:44 -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: > H. Peter Anvin wrote: >>> 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. > > Please explain what you're proposing again, because my memory of your > plan from last time wouldn't help in this case. Are you proposing that > the bzImage contains compressed data that its expecting the bootloader > to decompress? Won't that completely break backwards compatibility? If > we don't care about backwards compatibility with old bootloaders, then > it doesn't matter what we do one way or the other. > No, not at all. I'm proposing that the existing bzImage format be retained, but that the payload of the decompressor (already a gzip file) simply be vmlinux.gz -- i.e. a gzip compressed ELF file, notes and all. A pointer in the header will point to the offset of the payload (this is new, obviously.) The decompression stub is adjusted to expect an ELF image, instead of a raw binary. Existing bootloaders (16- or 32-bit) simply load the bzImage the way they do now; new bootloaders have the option of accessing the vmlinux.gz directly if they either want to load it themselves or want to examine the notes. -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/
Powered by blists - more mailing lists