From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] efi: Get the secure boot status [ver #6]
Date: Fri, 27 Jan 2017 14:01:01 +0000 [thread overview]
Message-ID: <20170127140101.GD31613@codeblueprint.co.uk> (raw)
In-Reply-To: <6306.1485209503@warthog.procyon.org.uk>
On Mon, 23 Jan, at 10:11:43PM, David Howells wrote:
> Matt Fleming <matt@codeblueprint.co.uk> wrote:
>
> > > (4) extract_kernel() calls sanitize_boot_params() which would otherwise clear
> > > the secure-boot flag.
> >
> > The ->sentinel flag should be clear (because you zero'd boot_params on
> > alloc), so the code inside of sanitize_boot_params() should never
> > trigger for the secure boot case.
>
> But it *does* trigger, otherwise I wouldn't've noticed this.
This looks like it's triggered because of a grub2 bug, if I'm reading
the code correctly (big if).
grub2 memcpy()'s 1024 bytes from the start of kernel image header into
the allocated (and zeroed) boot_params object. Unfortunately, it
should only be copying the second 512-byte chunk, not the first too.
The boot loader should only fill out those fields in the first 512
bytes that it understands. Everything else should be zero, which
allows us to add fields (and give them default non-zero values in the
header) in the future without breaking old boot loaders.
Something like this might fix it (not compiled tested). Could one of
the grub2 folks take a look?
---->8----
diff --git a/grub-core/loader/i386/efi/linux.c b/grub-core/loader/i386/efi/linux.c
index 010bf98..fe5771e 100644
--- a/grub-core/loader/i386/efi/linux.c
+++ b/grub-core/loader/i386/efi/linux.c
@@ -269,7 +269,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
loaded=1;
lh.code32_start = (grub_uint32_t)(grub_uint64_t) kernel_mem;
- grub_memcpy (params, &lh, 2 * 512);
+ grub_memcpy (params, (grub_uint8_t *)&lh[512], 512);
params->type_of_loader = 0x21;
next prev parent reply other threads:[~2017-01-27 14:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 12:30 [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #6] David Howells
2016-12-08 12:30 ` [PATCH 1/8] efi: use typed function pointers for runtime services table " David Howells
2016-12-08 12:30 ` [PATCH 2/8] x86/efi: Allow invocation of arbitrary runtime services " David Howells
2016-12-08 12:30 ` [PATCH 3/8] arm/efi: " David Howells
2016-12-08 12:30 ` [PATCH 4/8] efi: Add SHIM and image security database GUID definitions " David Howells
2016-12-08 12:30 ` [PATCH 5/8] efi: Get the secure boot status " David Howells
2017-01-11 14:33 ` Matt Fleming
2017-01-11 15:27 ` David Howells
2017-01-16 14:49 ` Matt Fleming
2017-01-16 15:39 ` David Howells
2017-01-23 21:26 ` Matt Fleming
2017-01-23 22:11 ` David Howells
2017-01-27 14:01 ` Matt Fleming [this message]
[not found] ` <25118.1485778229@warthog.procyon.org.uk>
2017-01-30 13:50 ` What should the default lockdown mode be if the bootloader sentinel triggers sanitization? Matt Fleming
2017-01-30 14:01 ` David Howells
2017-01-31 11:57 ` Matt Fleming
2017-01-31 14:02 ` [PATCH 5/8] efi: Get the secure boot status [ver #6] David Howells
2017-01-23 10:52 ` David Howells
2016-12-08 12:30 ` [PATCH 6/8] efi: Disable secure boot if shim is in insecure mode " David Howells
2016-12-08 12:31 ` [PATCH 7/8] efi: Handle secure boot from UEFI-2.6 " David Howells
2016-12-08 12:31 ` [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit " David Howells
2017-01-11 14:51 ` Matt Fleming
2017-01-11 15:29 ` David Howells
2017-01-16 13:40 ` Matt Fleming
2017-01-16 15:40 ` David Howells
2017-01-11 15:01 ` [PATCH 0/8] efi: Pass secure boot mode to kernel " Matt Fleming
2017-01-11 15:05 ` Ard Biesheuvel
2017-01-24 17:15 ` Ard Biesheuvel
2017-01-27 18:03 ` Ard Biesheuvel
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=20170127140101.GD31613@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).