From: Gary Lin <glin@suse.com>
To: hpa@zytor.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Joey Lee <jlee@suse.com>
Subject: Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header
Date: Fri, 8 Sep 2017 17:45:10 +0800 [thread overview]
Message-ID: <20170908094510.puqif3gvzms6hwrn@GaryWorkstation> (raw)
In-Reply-To: <2683B4EE-9BC5-4FCB-B880-C1A97163B24E@zytor.com>
On Thu, Sep 07, 2017 at 02:16:21PM -0700, hpa@zytor.com wrote:
> On September 7, 2017 2:44:51 AM PDT, Gary Lin <glin@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 <glin@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.biesheuvel@linaro.org>
> >> >> Cc: "H. Peter Anvin" <hpa@zytor.com>
> >> >> Cc: Thomas Gleixner <tglx@linutronix.de>
> >> >> Cc: Ingo Molnar <mingo@redhat.com>
> >> >> Cc: Joey Lee <jlee@suse.com>
> >> >> Signed-off-by: Gary Lin <glin@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
next prev parent reply other threads:[~2017-09-08 9:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 8:05 Gary Lin
2017-06-01 8:11 ` Gary Lin
2017-06-01 8:46 ` Ard Biesheuvel
2017-06-01 9:56 ` Gary Lin
2017-06-30 23:52 ` joeyli
2017-07-03 11:44 ` Ard Biesheuvel
2017-09-07 9:44 ` Gary Lin
2017-09-07 21:16 ` hpa
2017-09-08 9:45 ` Gary Lin [this message]
2017-09-08 20:59 ` hpa
2017-09-11 4:22 ` Gary Lin
2017-10-03 3:22 ` Gary Lin
2017-07-10 3:24 Gary Lin
2017-08-20 0:51 ` joeyli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170908094510.puqif3gvzms6hwrn@GaryWorkstation \
--to=glin@suse.com \
--cc=ard.biesheuvel@linaro.org \
--cc=hpa@zytor.com \
--cc=jlee@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®