Feature request for allowing hibernation with kernel lockdown

Hi,
I enabled the kernel lockdown feature during my recent install and found the kernel then blocks hibernation (unless you have a signed hibernation image, which does not exist yet). The logic makes sense except for two key points:

  1. Most / all users who enable Secure Boot / Lockdown are trying to keep their OS secure and verified, so they are already using full disk encryption
  2. Any users, such as myself, who have encrypted swap partitions or files have already mitigated the threat of an offline modification of any data in the hibernation image, so it would make more sense to only disable unencrypted hibernation.

I believe this decision was made upstream of SUSE but I assume openSUSE could patch something like this if they wanted to?

So my question is where’s the best place to post a request like this? Kernel.org? Opensuse bugzilla?

I don’t recall seeing that option for any 15.2 install. Can you point me on where to look on the installation screens?

Most / all users who enable Secure Boot / Lockdown are trying to keep their OS secure and verified, so they are already using full disk encryption

That seems doubtful.

Most users purchase a computer that already comes with secure-boot enabled. And they just go with the defaults. So they are using secure-boot, but most have not encrypted their disks.

In any case, the best place for an enhancement request appears to be the bugzilla.

Thanks, nrickert :good:

This was the first time I saw it too. I think it’s because I enabled Trusted Boot in BIOS and I’m using a new PC. I believe it was on the last settings screen before starting the install, and was called Trusted Boot. “Lockdown”, as I recall, is the kernel’s terminology.

That seems doubtful.
Most users purchase a computer that already comes with secure-boot enabled. And they just go with the defaults. So they are using secure-boot, but most have not encrypted their disks.

Yes, defaults for Windows and Mac users but I meant openSUSE users who, I assume, are mostly manually installing their OS. I’m just basing that on what I’ve seen on the web. Are there a lot of users buying PCs with open/SUSE pre-installed? I only know of Tuxedo and, very recently, Lenovo offering it as an option.

I don’t see a use case where a user wants to secure their bootloader and/or kernel but not their data or the rest of their system. Or for a user that enables Trusted Boot to secure the kernel from tampering but doesn’t replace the pre-installed corporate image.

You are talking about what make sense, rather than about what people actually do.

What is it? I am aware of “Secure Boot” and “Trusted Computing” and “Trusted Platform Module”, but I never saw “Trusted Boot” before.

Yes, it’s new to me too. Differenet than all of those. It’s a Linux Security Module, called Lockdown, that prevents users from modifying the kernel. Short overview here: mjg59 | Linux kernel lockdown, integrity, and confidentiality . Perhaps, Trusted Boot is the name for how Windows uses it.

You are seriously saying that you can enable Linux security module in BIOS? Besides, there is no linux security module called “trusted boot”.

Short overview here: mjg59 | Linux kernel lockdown, integrity, and confidentiality .

I know what linux kernel lockdown is. How is it related to BIOS setting called Trusted Boot?

… OK, it seems there actually is project called Trusted Boot which is using Intel TXT to launch verified kernel. It is highly unlikely that any BIOS setting will refer to this project, so we still do not know what you enabled, what it does and how it affects Linux kernel.

I has to do a search and this is one of the articles I found (but there is much more).
https://opensource.com/article/20/10/measured-trusted-boot
I guess it all start with the TPM
https://en.wikipedia.org/wiki/Trusted_Platform_Module

Nope, I confused TPM and Trusted Exectuion in the UEFI/BIOS with Trusted Boot in the SUSE installer. I believe when you enable Trusted Boot in the installer, then Lockdown is enabled. I haven’t tested this so it’s based on what I’ve read and what I saw play out during my installation last week. So no, we’re not turning on Linux modules from UEFI but rather enabling them to function.

As I understand, Enabling Secure Boot (and possibly TPM and then Trusted Execution) in UEFI allows enabling Trusted Boot in installer. I think this refers to the project you found, based on Intel’s TXT.

An interesting topic I don’t usually follow.
But, with the links provided by others in this thread plus some basic understanding of UEFI Secure Boot, it’s something that can be picked up immediately in a few minutes.

For those who might still find this unclear…
In my own words,

“Trusted Boot” is supposed to be a more precise description of the more common “Secure Boot” which is an option only when you configure a UEFI Boot configuration (and not the legacy MBR boot configuration). This is because contrary to its name “Secure boot” can be not that secure depending on what options are enabled. Are you using TPM (which is a hardware implementation storing your system’s cryptographic certs and hashes. It’s debatable whether this is more or less secure than storing in software)? Are you configured truly for Secure or Trusted boot which actively compares hashes (on demand created encryption secrets created and used on every cold boot and shutdown) or “Measured boot” which only creates the hashes for functional purposes but doesn’t actively compare to ensure integrity?

Secure boot (or Trusted Boot) is an important although debatable security necessity.
Everyone knows that every system is most vulnerable during bootup, since the first hacks were created rebooting has always been a common way to write malicious code when a system has barely started booting up, it’s just trying to get something to start working, much less apply complex security policy. As such, this can rarely or never be a problem solved by an OS, by the time the OS starts its boot process it can be too late. So, this is a problem that can be solved only by the BIOS/UEFI which is what this “Trusted Boot” is all about… How the system first starts up in a secure manner with full integrity which can then be extended to the OS, including the kernel.

But consider this…
Even without Secure Boot enabled, it’s very rare when the system itself and not just an application is compromised, and almost no actual incidents in the wild have been reported.

Just be aware though, that even UEFI Secure/Trusted Boot and TPM are not perfect… TPM has been compromised at least twice that I know of, and the Secure/Trusted Boot was compromised recently (last year? Or was that the year before?). Thankfully, in each case they were discovered in laboratory research and not in the wild. And, the recent Secure/Trusted boot compromise discovered about 2 months ago is due to an episode many years ago when the secret cryptographic secrets embedded in the UEFI chip were stolen and affects only the one manufacturer’s one model and usage of that chip… No other machines would be affected anywhere.

As for the Linux kernel lockdown,
The posted reference in this thread is very clear,
It’s not a method to protect data or information at rest or on bootup like Trusted Boot.
It may be implemented as an extension to the UEFI secure boot by continuing the chain of trust from boot to how the Linux kernel operates during runtime (not only when starting up, we’re talking about continuously until a cold shutdown) but I don’t know that it would be a requirement. In fact, I wouldn’t be surprised if someone who knows more about the SUSE kernel might say that kernel lockdown is always implemented, any option you might see in the boot configuration might only enable an option to tie kernel lockdown to the UEFI Secure boot process.
It likely has nothing to do with hibernation, or at least I would consider it a very inefficient way to verify integrity… I would not do an integrity check on every little thing in the hibernation file, I would instead do a single check on the entire file only.
It has to do with preventing the kernel from being modified during runtime, for instance by dynamically loading kernel modules.
As such, the User should be very careful about whether to enable kernel lockdown, to know whether any necessary kernel modules might not load due to a missing kernel signatures although I think nowadays all kernel modules should be signed. A likely example where this can be a problem is that from time to time the Virtualbox kernel modules have been improperly signed and need to be fixed.

TSU