On Fri, Sep 08, 2017 at 01:59:00PM -0700, h...@zytor.com wrote: > On September 8, 2017 2:45:10 AM PDT, Gary Lin <g...@suse.com> wrote: > >On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote: > >> On September 7, 2017 2:44:51 AM PDT, Gary Lin <g...@suse.com> wrote: > >> >On Thu, Jun 01, 2017 at 08:46:26AM +0000, Ard Biesheuvel wrote: > >> >> On 1 June 2017 at 08:11, Gary Lin <g...@suse.com> wrote: > >> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote: > >> >> >> A new section, secdata, in the setup header is introduced to > >store > >> >the > >> >> >> distro-specific security version which is designed to help the > >> >> >> bootloader to warn the user when loading a less secure or > >> >vulnerable > >> >> >> kernel. The secdata section can be presented as the following: > >> >> >> > >> >> >> struct sec_hdr { > >> >> >> __u16 header_length; > >> >> >> __u32 distro_version; > >> >> >> __u16 security_version; > >> >> >> } __attribute__((packed)); > >> >> >> char *signer; > >> >> >> > >> >> >> It consists of a fixed size structure and a null-terminated > >> >string. > >> >> >> "header_length" is the size of "struct sec_hdr" and can be used > >as > >> >the > >> >> >> offset to "signer". It also can be a kind of the "header > >version" > >> >to > >> >> >> detect if any new member is introduced. > >> >> >> > >> >> >> The kernel packager of the distribution can put the distro name > >in > >> >> >> "signer" and the distro version in "distro_version". When a > >severe > >> >> >> vulnerability is fixed, the packager increases > >"security_version" > >> >in > >> >> >> the kernel build afterward. The bootloader can maintain a list > >of > >> >the > >> >> >> security versions of the current kernels and only allows the > >> >kernel with > >> >> >> a higher or equal security version to boot. If the user is > >going > >> >to boot > >> >> >> a kernel with a lower security version, a warning should show > >to > >> >prevent > >> >> >> the user from loading a vulnerable kernel accidentally. > >> >> >> > >> >> >> Enabling UEFI Secure Boot is recommended when using the > >security > >> >version > >> >> >> or the attacker may alter the security version stealthily. > >> >> >> > >> >> > Any comment? > >> >> > > >> >> > >> >> This is now entirely x86-specific. My preference would be to have > >a > >> >> generic solution instead. > >> >> > >> >After check the headers again, another idea came to my mind: the > >MS-DOS > >> >stub. It's designed to show a warning while the image is loaded in > >> >DOS(*), > >> >but I wonder if it still matters. In the x86 linux efi header, the > >stub > >> >is just a 3-lines message, while arm64 completely ignores the stub. > >> > > >> >Since there is a offset to the PE header at 0x3c, we can > >theoretically > >> >put any thing between 0x40 and the PE header without affecting the > >> >current settings. > >> > > >> >HPA, > >> > > >> >Does the MS-DOS stub raise any concern to you? > >> > > >> >Thanks, > >> > > >> >Gary Lin > >> > > >> >(*) > >> > >>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_ > >> > > >> >> -- > >> >> Ard. > >> >> > >> >> > >> >> >> v2: > >> >> >> - Decrease the size of secdata_offset to 2 bytes since the > >setup > >> >header > >> >> >> is limited to around 32KB. > >> >> >> - Restructure the secdata section. The signer is now a > >> >null-terminated > >> >> >> string. The type of distro_version changes to u32 in case the > >> >distro > >> >> >> uses a long version. > >> >> >> - Modify the Kconfig names and add help. > >> >> >> - Remove the signer name hack in build.c. > >> >> >> > >> >> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > >> >> >> Cc: "H. Peter Anvin" <h...@zytor.com> > >> >> >> Cc: Thomas Gleixner <t...@linutronix.de> > >> >> >> Cc: Ingo Molnar <mi...@redhat.com> > >> >> >> Cc: Joey Lee <j...@suse.com> > >> >> >> Signed-off-by: Gary Lin <g...@suse.com> > >> >> >> --- > >[snip] > >> >> >> -- > >> >> >> 2.12.2 > >> >> >> > >> >> > >> > >> I really don't think that is a good idea. I would much rather keep > >this in a space we fully own. > >Fine. I'll find another place for ARM64 (probably append the structure > >right after the PE-header and denote the 2-byte offset in the reserved > >fields in the first 64 bytes header). > > > >Thanks, > > > >Gary Lin > > Another "safe" option would be to put it in a COFF segment; then it would be > system-independent.
Creating a new COFF section looks promising. Thanks for pointing the direction. Gary Lin