[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12411.1492211784@warthog.procyon.org.uk>
Date: Sat, 15 Apr 2017 00:16:24 +0100
From: David Howells <dhowells@...hat.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: dhowells@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Kyle McMartin <kyle@...hat.com>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"x86@...nel.org" <x86@...nel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
keyrings@...r.kernel.org,
Matthew Garrett <matthew.garrett@...ula.com>,
Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [PATCH 06/24] Add a sysrq option to exit secure boot mode
Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
> That does bring me to another EFI related point: many of these patches
> are x86 specific for no good reason.
Note that the sysrq one is awkward since the key chosen *is* arch-specific.
SysRq+x can't be arbitrarily assigned to this since some other arches have
their own use for it.
Anyway, the ones that are x86-specific are:
efi: Add EFI_SECURE_BOOT bit
efi: Lock down the kernel if booted in secure boot mode
Add a sysrq option to exit secure boot mode
Copy secure_boot flag in boot params across kexec reboot
x86: Lock down IO port access when the kernel is locked down
x86: Restrict MSR access when the kernel is locked down
asus-wmi: Restrict debugfs interface when the kernel is locked down
The first three are dealt with in the five patches I posted later, including
making the choice of sysrq key an arch override. The bits that can be moved
out to the efi firmware driver have been.
The 4th looks to be x86 bootloader protocol specific.
The remainder look very x86 specific, apart from one piece in the 5th patch
where /dev/port is locked down.
David
Powered by blists - more mailing lists