You’re probably familiar with virus scanners and similar security tools. These are effectively a block-list for bad software. They’re complex, they’re slow, and they aren’t always very effective.

Secure Boot is, effectively, an allow-list. It uses digital signatures to limit the set of software that can run in privileged mode. It’s a much more effective mechanism for blocking malware.

Social media threads on the topic frequently include dismissive comments about Secure Boot. I want to caution social media users to consider how well they know the people who make those comments and how much trust they have earned. They may claim that Secure Boot is not useful, but being unable to describe its use does not mean it has no use.

Understanding the Threat Landscape

Malware on any operating system tends to use software exploits to gain persistence. It typically does not rely on the user to run and authorize its access.

A lot of people look at Secure Boot as protecting the pre-boot environment, as if it is a brief event. It isn’t. In addition to the OS you interact with on a modern x86 system, there are (at least) two and a half other operating systems running at all times, with more control over the system than your primary OS. As this presentation explains, these lower-level systems have privileged access that your regular OS doesn’t have.

Secure Boot’s purpose is to protect your kernel and these lower-level operating systems from malware. This protection is critical because malware that gains kernel access is nearly impossible to detect (though it can usually be eliminated by wiping the drive and reinstalling), and malware that gains firmware access is both nearly impossible to detect and nearly impossible to remove. Real-world examples like this firmware bootkit demonstrate why this protection is essential. Rootkits that embed themselves in firmware are becoming more common, and Secure Boot is one of the recommended mitigations.

How Malware Escalates Privileges

Let’s walk through a concrete attack scenario to see how Secure Boot provides protection.

Once malware gets on your system, the malware is likely to begin execution in your user context. The POSIX multi-user design prevents malware from modifying the system outside what your user has permission to modify, unless it can leverage another exploit to get root.

Imagine that malware manages to gain access to a system, and further is able to use a local exploit to get root access. Maybe it joins a botnet at that point. It’s probably going to take extra steps in order to persist (which is to say that it’ll save itself to a file or download a file to execute in the future after a system reboot, and it’ll modify the boot process to execute that file). Now, unless it takes additional steps, it’s detectable. You can use “ps” to see it in the process list, or “ls” to see its files on disk.

How Malware Hides Itself

Many types of malware will take additional steps to hide themselves. The easy way to do that would be to modify “ps” and “ls” so that they no longer show the malware in their output. Simple, right? But what if you use “find” to look at files, or “top” to look at processes? What if you apply updates and overwrite the modified tools? A more complete hiding effort involves loading a kernel module to that the kernel itself no longer tells user-space about the malware’s files, processes, or network traffic! Now when the operator runs “ls /” or “find /”, the malware’s kernel module filters the responses to readdir(), and never includes files that contain the malware.

A modular kernel like Linux inherently allows loading software that can operate at a very low level, and can prevent anti-virus software from discovering and removing the malware.

How Secure Boot Prevents These Attacks

In a legacy design, root is the highest level of access, and nothing prevents malware from modifying the kernel or the system firmware. Secure Boot adds another level of separation, protecting the system firmware and the kernel from modification by malware.

Linux Secure Boot systems with kernel lockdown will not allow modules to load unless they are signed, and that makes it very difficult if not impossible for an attacker to load a kernel module that can hide malware. Malware can still modify user-space tools directly, to try to hide itself, but it’s much much easier to overcome that to determine if a system is infected or not.

Further Reading

For those interested in the technical details: