Why should I disable secure boot (other distros don't require this)

Total noob so forgive me.

I tried to install Clear on a new system.

Installer failed (forgot the exact error message - something about not being able to pass checks).

Found out I am supposed to disable secure boot.

But that sounds important. Why would Clear Linux “ask”/need me to do this?

Can I keep secure boot on and still install Clear?


Not currently. We still do not support booting with Secure Boot. While this is something that we want to support, it has unfortunately due to various circumstances never been completed.

1 Like

Secure boot is important. But it can be abused by vendors. Ideally, the computer you bought should belong to you and the vendor should help you keep it secure. But many vendors use Secure Boot to lock out (literally) other vendors and other software from running on your computer. This is not a Good Thing :tm:. By disabling Secure Boot you’re disabling the encryption keys your vendor installed on your computer. The encryption keys are what are preventing the checks in Secure Boot from passing. In an ideal world your vendor would tell you how to install your own keys to secure your computer, then you would be able to sign any OS you wanted to use. Until then, you’ll have to disable Secure Boot to bypass the vendor restrictions.

Look into Coreboot or Libreboot to see alternatives to proprietary BIOSes.


If there are manufacturers that don’t allow this, then surely they would be known as Linux hostile? Are there actually vendors that still do this?

We’ve received many comments from users asking us to support Secure Boot. We wouldn’t have this on our list of TODO things unless it was wanted by users, either. It will continue to be on our TODO list until we solve the problems we’re having to complete this.

If there are manufacturers that don’t allow this, then surely they would be known as Linux hostile? Are there actually vendors that still do this?

I mean hardware vendors when I use the term “vendors” here, I should probably use ODM or OEM.

Most ODM’s are not shipping non-proprietary BIOS with the device. Is there a way to know how things like the TPM are used (or not used) for Secure Boot if the vendor doesn’t allow you to audit the code? Without knowing what each ODM does with their BIOS it is hard to know how and where to install your own keys, under your control, for Secure Boot.

Can you be more specific? I recognize that the answer might be no because that information may be a business secret, but it would be good to know that if it is the case.

This is mostly an operational problem, getting something signed once is doable, but scaling it to production levels is proving challenging. For instance, in case of a major security issue, we need to be able to get it signed in just a few hours.

Thank you, that is helpful.

You mean to say that one can swap his own BIOS/UEFI?

Again, I am a noob into this.

Also, just curious, why is it that other distros are able to install without asking us to disable secure boot?

Thanks so much

Yes, you can swap out the BIOS in some instances - it depends on the specific motherboard and chips you have. Look at Coreboot’s site or Libreboot.

I don’t know why other distros are able to install without disabling secure boot, it may depend on Clear Linux settings or your computer’s setting.

The way that secure boot works is that there are verification keys stored in your UEFI firmware which some people still refer to as a BIOS. There is a platform key which allows the KEK database to be modified. There is a Key Exchange Key (KEK) which allows the db and dbx to be modified. The db is the authorized database of keys and dbx is the forbidden database if a key gets compromised. For the purpose of getting secure boot to work on Windows, Microsoft has worked with most of the major OEM’s and ODM’s to get their verification keys embedded into most UEFI firmware that ships. Almost any computer your buy will already have a Microsoft key embedded into the UEFI firmware. You can read more about this process at the UEFI site.

When you turn your system on and secure boot is enabled, the keys in your UEFI firmware verify the integrity of the first stage bootloader. If a single bit is different then the hash won’t match and the verification fails. Your system won’t boot. After the first stage is verified and loaded it has its own encryption keys embedded that are used to verify the second stage which has its own key to verify the kernel. It is a chain of trust. In Clear Linux the second stage and kernel have embedded keys and continue the secure boot process. The only thing left to do is to sign the first stage with the Microsoft key so that existing systems with their existing PK, KEK, and db keys can do a full secure boot chain of trust verification. This is how other Linux distributions like Ubuntu are able to do secure boot.

You can track the status of our Secure Boot enabling in our GitHub distribution. https://github.com/clearlinux/distribution/issues/234


Good explanation @eadams, thanks.

I wanted to point out something that it says in the Ubuntu wiki link you shared;

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work.

If you’re truly paranoid, you might not want to trust MSFT keys. Also, many who value software freedom and security want to have greater control of the boot process because it is proprietary and subject to supply chain attacks. This is why there is a need for tools like Coreboot which gives you control over the keys that live on the Trusted Platform Module and are used at boot time. That way you can use your own keys, created by you, in firmware, on your device.


You could do this right now with Clear Linux. The process would be that you would need to sign the first stage bootloader or the shim as we refer to it internally. It is located at /boot/EFI/org.clearlinux/tooloaderx64.efi and you would have to use sudo systemctl start boot.mount to get to that file.

However, at some point in the future we will sign this shim to support secure boot and a swupd update will replace that file. You would have to re-sign that file and ensure they verification keys are in UEFI firmware. It is not a file that changes very often, but if it did then swupd would replace it. This is not a process we support but it should work. There are guides online that would give you clues on how to exactly do this. Like I said though it is not something we support.

1 Like

In pretty much all x86 motherboards (by which I mean I can’t find any exception,) the key database is entirely controllable by the end user. If you want to add your own key, you can. If you want to delete microsoft’s key, you can. The only way that microsoft is involved is that 1) the majority of motherboards ship by default with MS’s key, and 2) for a computer to be designated “Certified for Windows 8 or 10 or whatever” it has to ship with Secure Boot enabled by default and have Microsoft’s key. It does not prevent user management of the keys.

Paul Aiton is an AWS, Redhat Linux, AIX, Solaris, etc… certified and security hardening expert.

From me:

It’s named Custom Mode / Key management. You can find it at secure boot menu in your computer “BIOS” (EFI now) and you can remove all MS keys right now (and restore to defaults any time)

More explained at r/linux: How and why is UEFI’s Secure Boot useful? post contains clear explanation and link to Linus Torvalds interview about this.