[personal profile] mjg59
David Howells recently published the latest version of his kernel lockdown patchset. This is intended to strengthen the boundary between root and the kernel by imposing additional restrictions that prevent root from modifying the kernel at runtime. It's not the first feature of this sort - /dev/mem no longer allows you to overwrite arbitrary kernel memory, and you can configure the kernel so only signed modules can be loaded. But the present state of things is that these security features can be easily circumvented (by using kexec to modify the kernel security policy, for instance).

Why do you want lockdown? If you've got a setup where you know that your system is booting a trustworthy kernel (you're running a system that does cryptographic verification of its boot chain, or you built and installed the kernel yourself, for instance) then you can trust the kernel to keep secrets safe from even root. But if root is able to modify the running kernel, that guarantee goes away. As a result, it makes sense to extend the security policy from the boot environment up to the running kernel - it's really just an extension of configuring the kernel to require signed modules.

The patchset itself isn't hugely conceptually controversial, although there's disagreement over the precise form of certain restrictions. But one patch has, because it associates whether or not lockdown is enabled with whether or not UEFI Secure Boot is enabled. There's some backstory that's important here.

Most kernel features get turned on or off by either build-time configuration or by passing arguments to the kernel at boot time. There's two ways that this patchset allows a bootloader to tell the kernel to enable lockdown mode - it can either pass the lockdown argument on the kernel command line, or it can set the secure_boot flag in the bootparams structure that's passed to the kernel. If you're running in an environment where you're able to verify the kernel before booting it (either through cryptographic validation of the kernel, or knowing that there's a secret tied to the TPM that will prevent the system booting if the kernel's been tampered with), you can turn on lockdown.

There's a catch on UEFI systems, though - you can build the kernel so that it looks like an EFI executable, and then run it directly from the firmware. The firmware doesn't know about Linux, so can't populate the bootparam structure, and there's no mechanism to enforce command lines so we can't rely on that either. The controversial patch simply adds a kernel configuration option that automatically enables lockdown when UEFI secure boot is enabled and otherwise leaves it up to the user to choose whether or not to turn it on.

Why do we want lockdown enabled when booting via UEFI secure boot? UEFI secure boot is designed to prevent the booting of any bootloaders that the owner of the system doesn't consider trustworthy[1]. But a bootloader is only software - the only thing that distinguishes it from, say, Firefox is that Firefox is running in user mode and has no direct access to the hardware. The kernel does have direct access to the hardware, and so there's no meaningful distinction between what grub can do and what the kernel can do. If you can run arbitrary code in the kernel then you can use the kernel to boot anything you want, which defeats the point of UEFI Secure Boot. Linux distributions don't want their kernels to be used to be used as part of an attack chain against other distributions or operating systems, so they enable lockdown (or equivalent functionality) for kernels booted this way.

So why not enable it everywhere? There's a couple of reasons. The first is that some of the features may break things people need - for instance, some strange embedded apps communicate with PCI devices by mmap()ing resources directly from sysfs[2]. This is blocked by lockdown, which would break them. Distributions would then have to ship an additional kernel that had lockdown disabled (it's not possible to just have a command line argument that disables it, because an attacker could simply pass that), and users would have to disable secure boot to boot that anyway. It's easier to just tie the two together.

The second is that it presents a promise of security that isn't really there if your system didn't verify the kernel. If an attacker can replace your bootloader or kernel then the ability to modify your kernel at runtime is less interesting - they can just wait for the next reboot. Appearing to give users safety assurances that are much less strong than they seem to be isn't good for keeping users safe.

So, what about people whose work is impacted by lockdown? Right now there's two ways to get stuff blocked by lockdown unblocked: either disable secure boot[3] (which will disable it until you enable secure boot again) or press alt-sysrq-x (which will disable it until the next boot). Discussion has suggested that having an additional secure variable that disables lockdown without disabling secure boot validation might be helpful, and it's not difficult to implement that so it'll probably happen.

Overall: the patchset isn't controversial, just the way it's integrated with UEFI secure boot. The reason it's integrated with UEFI secure boot is because that's the policy most distributions want, since the alternative is to enable it everywhere even when it doesn't provide real benefits but does provide additional support overhead. You can use it even if you're not using UEFI secure boot. We should have just called it securelevel.

[1] Of course, if the owner of a system isn't allowed to make that determination themselves, the same technology is restricting the freedom of the user. This is abhorrent, and sadly it's the default situation in many devices outside the PC ecosystem - most of them not using UEFI. But almost any security solution that aims to prevent malicious software from running can also be used to prevent any software from running, and the problem here is the people unwilling to provide that policy to users rather than the security features.
[2] This is how X.org used to work until the advent of kernel modesetting
[3] If your vendor doesn't provide a firmware option for this, run sudo mokutil --disable-validation

You still missed the basic.

Date: 2018-04-05 10:03 am (UTC)
From: (Anonymous)
"If you're running in an environment where you're able to verify the kernel before booting it (either through cryptographic validation of the kernel, or knowing that there's a secret tied to the TPM that will prevent the system booting if the kernel's been tampered with), you can turn on lockdown."

Neither is required. The kernel/bootloader could be on read only media. Like booting from a live disc. A system using a solution like this may be a pre UEFI one.

So no cryptographic or TPM turning lockdown on there is valid cases.

Having to disable validation of kernel to disable lockdown is highly invalid.

Just because Linux distributions mandate lockdown feature does not mean people building their own kernels want lockdown or people doing a development process on a device want to always have lockdown in way.

Allowing distributions to build with lockdown on does not mean that you cannot provide the features to allow kernels to be built with lockdown off.

Also not provide the option for when it safe to have lockdown without secure boot is a mistake as well.

Date: 2018-04-05 10:55 am (UTC)
From: (Anonymous)
There might actually be a reason to enable it everywhere if it is compiled in the kernel and that is a developer currently (ab)using features that will get restricted with lockdown, especially if said developer is running his own kernel, didn't set up secure boot and/or is on a distro that doesn't turn this on.

For example lets say such a developer is using distro X which doesn't compile the kernel with lockdown enabled now they get a bug report from someone using distro Y which does have lockdown enabled but from the bug report this might not be clear. The dev can't reproduce it and so tries to get distro Y installed in a VM but this VM has no EUFI secure boot so lockdown doesn't get enabled and thus still can't get it to reproduce.

I think there are 2 ways around this the first is to have lockdown always enabled even on non-secure boot platforms (if it is compiled in the kernel) or have the kernel (or other) logging/errors be explicit in why something got blocked (haven't looked at this so might already be in, hopefully)

Does this make sense or am I just rambling here?
From: (Anonymous)
Based on your explanation I can only see that it restricts the owner of a device (usually he is the only root, otherwise you would have other things to worry than secure booting a machine anyway...). If this is done solely in the interest of security (of whom?) then there should be a way to disable vendor keys on a device that I own. I don't see how I should be able to trust UEFI secure booot either, it is just another binary blob that a user is forced to trust without open source.


Date: 2018-04-05 02:21 pm (UTC)
From: (Anonymous)
Hi Matthew.

One of the problems i guess is some just don't want Linux to be good at things like secure boot or DRM ... Now the question i guess is can you blame them?

Here we go again.

Date: 2018-04-05 10:54 pm (UTC)
From: (Anonymous)
More bullshit masking as security that will help eliminate general purpose computing and lock the user out of his own device.

Who is pushing this? I mean, really? Do you still work for Rat Crap and what do they have invested here?

You're not making much sense

Date: 2018-04-06 07:20 pm (UTC)
From: (Anonymous)
You're saying: "Distributions would then have to ship an additional kernel that had lockdown disabled (it's not possible to just have a command line argument that disables it, because an attacker could simply pass that), and users would have to disable secure boot to boot that anyway."

If I understand your article, disabling UEFI secure boot automatically disables lockdown mode (and if not, why not?), so why do you need another kernel with lockdown disabled by default to be shipped? And you really think that a user is going to be able to distinguish between two official kernels, both shipped by the distributor? Why would an attacker not force that kernel to be booted when he gets control over the machine?

Having a command line parameter to disable lockdown would make it obvious both in the journald logs or in /proc/cmdline. Part of me thinks though that user friendliness is not your goal here, only providing some fuzzy feelings of "magic" security that can be withdrawn at any time if the user does "naughty" things.
From: (Anonymous)

In the pass you talked about EFI Variable Storage Reclaim in UEFI.

I using Phoenix Secure Core 2.2.3. I rolled Bios back in T/S an issue. Tried to roll it forward later but could not. EVSA Exhausted out of space. I've rebooted to the machine many times. Reclaim of EFI variable space does not seem to happen.
If tell the Dosflash or ShellFlash64 to flash my Capsule is falls thru because of the error. I add a /cvar option to clear variables but I don't think thats executed because it must first check security of a capsule that wasn't loaded because of the error. Plus clear isn't the same thing as reclaim in my mind.

I've been search for a clear method to force the reclaim process to enage and clean up the EFI Variable space. I found one method on Count Chu blog post from 2014. "ToolB.EFI". But he never list the the souce of the tool or a copy of it for download.

I've seen some of your posts too on the matter. I'm noted today something was done in linux kernel 3.9.7 too with regard to proper report of EFI variable free space in "EFI.C". And it made it in that kernel.

Do have any method that would force the reclaim function to engage. From Linux? From Shell64?

User vs Distribution

Date: 2018-04-08 01:23 am (UTC)
From: (Anonymous)
So, one of your arguments from this post is that there is no way to enforce the kernel cmdline if booted as an EFI executable, but I am doing exactly that since quite some time: I roll the kernel, initrd and cmdline into one EFI binary and then sign that.
AFAIK this prevents anyone from changing the cmdline (please correct me if I am wrong). I think I even learned about this possibility from this very blog :)

However, I think I realize why this "doesn't count" for your argumentation: It would be highly impractical for a distribution to ship this signed blob, as the initrd is usually generated on the users system and the cmdline might also need to account for the users individual setup (root partition or mount arguments at least).
So from a Distributions perspective I want lockdown linked to UEFI because then I can sign this lockdown-enabled kernel, ship it, and guarantee to every user that - if secure boot is on and my keys are enrolled in the firmware - whatever kernel or OS may have been booted or chainloded into, it was signed by me and hadn't be tampered with.

I already see a problem with this: How can the user check if secure boot is actually enabled? If someone managed to compromise the system and turn secure boot off (for example by using shim), they could just boot a system that makes it look like secure boot is enabled.
But this is not my main problem with the patch:

Currently, I am using my distributions prebuilt kernel, as I've had no need for custom kernel options since a long time. I also use secure boot to verify my kernel+initrd+cmdline, as mentioned earlier. I don't really trust the proprietary implementation of it, but it's better than not using secure boot. Everything besides the UEFI boot partition is encrypted, so I "use" this encryption to further verify my boot chain. I know that it's theoretically possible to tamper with an encrypted disk without knowing the encryption key, but again better than nothing.
So I really don't want to disable secure boot, but I might want to disable lockdown (and I can imagine that there are more people who want that than just me). Maybe I want to chainload into something unsigned, but I (sufficiently) trust it because it comes from my encrypted disks.
But if my distribution enables the lockdown option as is, I would have to build my own kernel from now on, until possibly forever. I might even have to maintain my own patch set if I want to leave lockdown available as a cmdline option, but not tie it to secure boot!
That, or the distribution still would have to ship two kernels: One with lockdown tied to secure boot, signed; one with lockdown not tied to secure boot, unsigned.

So, this might actually be a user vs distribution thing. The user wants to disable lockdown without disabling secure boot, but the distribution wants to be able to give guarantees to other users (or maybe other software vendors).

As a user, I don't want to accept the lockdown patches as is. But I think there is another way to solve this, which might be acceptable to Distributions: The distribution ships a tiny signed bootloader that enforces the lockdown argument on the cmdline. The kernel is then signed in a different way, so it can't be booted directly with secure boot but only via the bootloader. There is still an amount of work needed for this (mainly signing the kernel in this "different way"), but it probably beats shipping two kernels, one with a possibly out-of-tree version of lockdown. And I would definitely prefer this over rolling my own kernel from now ;)

Another tiny thing: If the current lockdown patches allow for lockdown to be disabled with alt-sysrq-x during runtime, wouldn't this invalidate all the efforts of lockdown? Say I boot a signed Fedora, disable lockdown, then somehow chainload into a modified Windows which sees secure boot is still active?

When it all started ...

Date: 2018-04-08 09:32 am (UTC)
From: (Anonymous)
When it all started ... https://www.phoronix.com/scan.php?page=news_item&px=Kernel-Lockdown-Patches
[Kernel Lockdown Patches Published (LOCK_DOWN_KERNEL) - 17 Nov 2016]
From: (Anonymous)
Hey Matthew,
I've reported a bug in the (your?) kexec secure boot implementation with regards to custom platform keys in march: https://bugzilla.redhat.com/show_bug.cgi?id=1554113, but unfortunately have not received any responses (even though another user confirmed the bug).

Could you please have a look at it?

Re lockdown mode

Date: 2018-11-21 08:52 am (UTC)
From: (Anonymous)
I don't think all lockdown features should be enabled on UEFI secure booted systems. On laptops, one can, for example, have OPAL self encrypting drives that are unlocked transparently before the OS (or the bootloader for that matter) have any chance of knowing about it. In this case, the blocking of hibernation is not needed since the resume partition is encrypted.
Also in the case of laptops, some power management functionality is needed that can only be accessed through MSR and other unorthodox methods. This makes it so that laptop owners have two choices: either disable secure boot and have a full-featured laptop or enable secure boot and have a crippled laptop. I think a third choice would be a generous offer to laptop users to be able to have the most secure system possible while retaining important laptop functionality.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags