On Thu, Feb 13, 2020 at 07:10:49PM -0500, Arvind Sankar wrote: > On Thu, Feb 13, 2020 at 10:36:14PM +0000, Ard Biesheuvel wrote: > > 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 > > Yeah, but doing that will allow you to boot directly from firmware on > existing machines, and only one image needs to be chosen at install > time, so it just adds a few MiB to the package. I guess most people will > still use a boot manager or loader that can be easily enhanced to use > LoadImage and the new section, but it would be nice to have the option > to avoid that. Also not quite today, right? You still need this patchset and the modifications to bootloaders to get away with one image.
