On Thu, 13 Feb 2020 at 19:47, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > On Thu, Feb 13, 2020 at 05:55:44PM +0000, Ard Biesheuvel wrote: > > On Thu, 13 Feb 2020 at 18:53, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > As an alternative to the new section, how about having a CONFIG option > > > to emit the 64-bit kernel with a 32-bit PE header instead, which would > > > point to efi32_pe_entry? In that case it could be directly loaded by > > > existing firmware already. You could even have a tool that can mangle an > > > existing bzImage's header from 64-bit to 32-bit, say using the newly > > > added kernel_info structure to record the existence and location of > > > efi32_pe_entry. > > > > > > > That wouldn't work with, say, signed distro kernels. > > No, the idea would be that the distro would distribute two signed > images, one 32-bit and one 64-bit, which are identical except for the > header. At install time, the installer chooses based on the system's > firmware bit-ness. > I guess it would be possible, but then we'd need two different images while today, we can run the same image on both kinds of firmwares. The only thing I am trying to do is remove all the quirky bootparams stuff from the loader so that we can switch to LoadImage > > > > > Also, the PE header can live anywhere inside the image, right? Is there > > > any reason to struggle to shoehorn it into the "boot sector"? > > > > It cannot. It must live outside a region described by the section headers. > > It could still be inserted after .setup, or at the very end of the file, no? The PE/COFF spec mentions that the COFF header needs to follow the signature. Also, the SizeOfHeaders field would become somewhat ambiguous if the header is split up like that.
