From: David Howells <dhowells@redhat.com>
To: Matt Fleming <matt@codeblueprint.co.uk>,
Peter Jones <pjones@redhat.com>,
mjg59@srcf.ucam.org
Cc: dhowells@redhat.com, ard.biesheuvel@linaro.org,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"H. Peter Anvin" <hpa@zytor.com>, Michael Chang <mchang@suse.com>
Subject: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?
Date: Mon, 30 Jan 2017 12:10:29 +0000 [thread overview]
Message-ID: <25118.1485778229@warthog.procyon.org.uk> (raw)
In-Reply-To: <6306.1485209503@warthog.procyon.org.uk>
Hi all,
There's an interesting issue with the way the x86 boot parameters are passed
into the kernel if we want to store the secure-boot mode flag in there.
My patches add boot_params->secure_boot, into which is placed the secure boot
mode as deduced by the EFI boot wrapper, if it is invoked. This, however,
gets scrubbed by sanitize_boot_params() if the ->sentinel flag is set. It
turns out that grub2 has a bug in it whereby it initialises boot_params by
copying the wrong stuff over it, thereby setting the ->sentinel flag.
In my patch I saw that sanitisation was happening and I stopped
sanitize_boot_params() from clobbering that particular byte and instead zeroed
it on entry to the boot wrapper. This seemed reasonable since the boot
wrapper calculates the flag and simply overwrites whatever the boot loader had
placed there - and the value was getting clobbered by sanitisation called
during kernel decompression.
Matt argues, however, that boot_params->secure_boot should be propagated from
the bootloader and if the bootloader wants to set it, then we should skip the
check in efi_main() and go with the bootloader's opinion. This is something
we probably want to do with kexec() so that the lockdown state is propagated
there.
However, what should happen in the core kernel if the bootloader doesn't
properly initialise ->sentinel and sanitisation is done that then clobbers
->secure_boot? Should the kernel be locked down by default or left open by
default if lockdown was enabled in the kernel config?
But, as I mentioned, a bug in grub2 whereby it is copying the wrong
initialisation data over boot_params is causing sanitisation to be triggered.
Some questions that should clarify how we proceed:
(1) Do we actually want to propagate the mode determination from the boot
loader?
(2) Do we have to determine the secure-boot status in the EFI boot wrapper
(we don't use it there) or can we determine it in the core kernel?
(3) What's the default mode in the case of sanitisation when lockdown is
configured?
(4) How do we handle the initialisation being mucked up such that ->sentinel
ends up 0 and ->secure_boot ends up essentially random?
Any thoughts?
David
next prev parent reply other threads:[~2017-01-30 12:11 UTC|newest]
Thread overview: 30+ 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
2017-01-30 12:10 ` David Howells [this message]
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=25118.1485778229@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=hpa@zytor.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mchang@suse.com \
--cc=mjg59@srcf.ucam.org \
--cc=pjones@redhat.com \
/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
Powered by JetHome