What Secure Boot Is and How Shim Files Work in Linux

What Secure Boot Is and How Shim Files Work in Linux

If you’re installing Linux on a modern computer, sooner or later you might encounter a situation where the system suddenly stops booting — especially after an update or a new kernel installation. In many cases, the culprit is Secure Boot being enabled in your UEFI settings.

Secure Boot is supposed to enhance security by preventing unverified software from running during the earliest stages of system startup. In practice, however, it sometimes becomes a source of trouble for Linux users.

A good example is what happened with Ubuntu 21.04: the shim files responsible for enabling Secure Boot on Linux turned out to be incompatible with certain older EFI firmware versions. As a result, after an update the system refused to boot, and users had to manually figure out how to restore functionality — in some cases even by reverting to shim files from a previous release.

To understand what happens “under the hood,” let’s break down how Secure Boot works, what shim files do, and in which cases you might want to turn this feature off.

What Secure Boot Is — Explained Simply

Imagine your computer as a building with a security guard at the entrance. Secure Boot is that guard: it checks the “documents” of every program trying to run during system startup. If the signature is valid and trusted, it lets the program through. If the signature is missing or blacklisted, the program is blocked even before the operating system begins loading.

Secure Boot is part of the UEFI technology that replaced the traditional BIOS. UEFI handles the early boot process and prepares the system to load the OS. When Secure Boot is enabled, the firmware only allows components signed with trusted cryptographic keys to run.

The idea is simple: prevent malicious code from injecting itself into the boot chain and executing before the OS, where it would be harder to detect and remove.

How Secure Boot Works

Behind the scenes, Secure Boot relies on a set of keys and databases that determine which software is trusted. In simplified terms, these components are involved:

Platform Key (PK) — the system’s primary key, usually set by the device manufacturer (Dell, HP, etc.). It defines who is allowed to manage Secure Boot policies.

Key Exchange Key (KEK) — a set of keys permitted to add or remove trusted certificates and database entries. This acts as a “bridge” between the firmware and the bootloaders.

Allowed Database (DB) — the list of trusted signatures. Anything in this database can be executed when Secure Boot is active.

Forbidden Database (DBX) — the list of banned signatures. If a program or bootloader is listed here, Secure Boot blocks it.

During startup, the firmware checks every element of the boot chain — loaders, modules, drivers. If a signature matches the trusted keys and databases, the component is allowed to execute. If not, the boot process is stopped or a warning is displayed.

What Shim Files Are and Why Linux Needs Them

Now imagine you’re installing Linux on a machine with Secure Boot enabled. Windows typically already has trusted signatures in the firmware, but Linux may not. To convince Secure Boot to allow Linux to run, Linux distributions use a special intermediary bootloader called shim.

A shim is a small “bridge” program between Secure Boot and the main Linux bootloader.

The crucial point is that shim itself is signed with a key trusted by the firmware — most often a Microsoft signature, because Microsoft’s certificates come pre-installed in UEFI on many devices.

After that, the process works like this:

  1. Secure Boot verifies shim’s signature and allows it to run.

  2. Shim verifies the signature of the Linux bootloader according to its own rules.

  3. If everything checks out, shim hands control to the Linux bootloader, which then loads the kernel and the system.

This forms a chain of trust:
 UEFI → Secure Boot → shim → Linux bootloader → kernel

Thanks to this, Linux can boot on systems where Secure Boot is enabled.

Why Secure Boot Matters at All

Secure Boot was introduced for a reason. It helps protect against one of the most dangerous types of malware — bootkits and rootkits that embed themselves into the boot chain and run before the operating system.

Such malware:

  • intercepts control before the OS starts,

  • integrates deeply into the system,

  • is difficult for regular antivirus tools to detect,

  • can be hard to remove without a full system reinstall.

From a security standpoint, the approach makes sense. But in the Linux world, there’s another side to the story.

When Secure Boot Gets in the Way

For Linux users, Secure Boot can sometimes cause more issues than it solves. Common problem scenarios include:

  1. Installing a distribution without Secure Boot support.
     Not all Linux distributions ship with the necessary signatures. If your system isn’t prepared for Secure Boot, it simply won’t boot while the feature is enabled.
  2. Using third-party drivers and kernel modules.
     Proprietary drivers, some kernel modules, and alternative bootloaders may not be signed — or may be signed with keys the firmware doesn’t trust. The result: boot errors, failed installations, or non-functioning drivers.
  3. Advanced system customization.
     If you compile your own kernel, experiment with nonstandard loaders, or test experimental modules, Secure Boot will get in the way. Many advanced users turn it off for more flexibility.

In many cases, installing proprietary graphics drivers is nearly impossible without disabling Secure Boot, because the driver won’t install or load otherwise.

Which Linux Distributions Support Secure Boot?

Despite compatibility issues, most major Linux distributions have adapted to Secure Boot and now ship signed bootloaders and shim files.

Secure Boot is typically supported by:

  • Debian, Ubuntu, and derivatives

  • Red Hat and Fedora

  • openSUSE and SUSE

Before installing a specific distribution, it’s best to check its documentation — it usually states whether Secure Boot is supported and whether a signed shim or bootloader is provided. If not, you have two options: disable Secure Boot in UEFI or manually enroll your own keys and loaders.

How to Disable Secure Boot

If Secure Boot causes more trouble than benefit, you can turn it off. The exact steps depend on your motherboard manufacturer, but the general sequence is:

  1. Reboot and enter UEFI setup.
     Press F2, F10, Esc, or Del during startup. The correct key is usually shown on the screen or listed in the manual.

  2. Find the Secure Boot setting.
     It’s usually located in the Boot, Security, or Authentication section. Sometimes it appears in advanced settings.

  3. Set Secure Boot to “Disabled.”
     Save the changes (often with F10 or Save & Exit) and reboot.

After this, the system will boot without early signature checks, and Linux distributions or third-party drivers will no longer run into Secure Boot restrictions. Of course, you give up an additional layer of protection.

The Mixed Opinions on Secure Boot in the Linux Community

Linux users have long had an ambivalent view of Secure Boot. On one hand, it was created with good intentions — strengthening security and protecting against sophisticated threats. On the other hand, it imposes strict limitations, especially for those using less common distributions or proprietary drivers.

There’s also the dependency on Microsoft-issued signatures: many distributions rely on shim files signed with keys trusted by UEFI firmware. This effectively ties the ability to boot alternative operating systems to a single major vendor.

Additionally, if you rely on proprietary GPU drivers, you often face a choice: enable Secure Boot for additional protection, or disable it to ensure your drivers work properly.

Ideally, users wouldn’t have to make such trade-offs — but for now, this is the reality.

With this understanding of Secure Boot, shim files, and the trust chain involved in system startup, diagnosing and resolving Linux installation or update issues becomes much easier.