On Thu, Apr 13, 2017 at 03:21:20PM -0700, hpa@xxxxxxxxx wrote: > On April 11, 2017 3:20:41 AM PDT, Gary Lin <glin@xxxxxxxx> wrote: > >This commit adds the new config options to allow the user to modify the > >following fields in the PE-COFF header. > > > >UINT16 MajorOperatingSystemVersion > >UINT16 MinorOperatingSystemVersion > >UINT16 MajorImageVersion > >UINT16 MinorImageVersion > > > >Those fields are mainly for the executables or libraries in Windows NT > >or higher to specify the minimum supported Windows version and the > >version of the image itself. > > > >Given the fact that those fields are ignored in UEFI, we can safely > >reuse > >those fields for other purposes, e.g. Security Version(*). > > > >(*) https://github.com/lcp/shim/wiki/Security-Version > > > >Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > >Cc: Ingo Molnar <mingo@xxxxxxxxxx> > >Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> > >Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> > >Cc: Michal Marek <mmarek@xxxxxxxx> > >Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> > >Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > >Cc: Joey Lee <jlee@xxxxxxxx> > >Cc: Vojtech Pavlik <vojtech@xxxxxxx> > >Signed-off-by: Gary Lin <glin@xxxxxxxx> > >Tested-by: Joey Lee <jlee@xxxxxxxx> > >--- [snip] > > Reusing PECOFF fields seems doubleplusunsafe: we don't own those fields, the UEFI forum does. It would make a lot more sense to add these fields to the bzImage header directly or indirectly (via a pointer), the latter would be more economical since the bzImage header size is bounded. > > We could even define it as a pointer to a "security information header" with its own size field, so it can be grown in the future as needed. Reusing PE-COFF simplifies the implementation since shim can parse the header directly. I can raise the issue to the UEFI forum to clarify the usage of those fields. Meanwhile, I'll also look into the bzImage header in case the PE-COFF header is really a NO-GO. Thanks, Gary Lin -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
