All my partitions are encrypted (/ and /home), but the /boot partition has to remain unencrypted and is open for manipulation. I was thinking about hashing the kernel on bootup and checking the result against a stored value (generated on compile, saved on my encrypted drive) to see if someone, somehow manipulated the kernel since the last boot (maybe even physically). Is there a problem with writing such a script? Are there programs that do this already?

2 Answers 2


What you're looking for — verifying that the operating system running on the computer is one you trust — is called trusted boot. (It's one of several things that are sometimes called trusted boot). Your proposed method does not achieve this objective.

Encryption does not provide data integrity or authenticity. In other words, it does not prevent an attacker from modifying the contents of your disk and replacing it by a malicious operating system. This malicious operating system could easily be programmed to show the checksum that you expect for the loaded kernel.

The easiest path of attack is a man-in-the-middle where the attacker runs your normal operating system under some kind of virtual machine. The virtual machine layer transmits your input to your desired operating system and transmits output back. But it also records your keystrokes (mmmm, passwords) on the side, snoops private keys from the OS's memory and so on.

In order to avoid this form of attack, you need to have a root of trust: a component of the system that you trust for a reason other than because some other component of the system says so. In other words, you have to start somewhere. Starting with hardware in your possession is a good start; you could keep your operating system on a USB key that doesn't leave your sight, and plug that only in hardware that you have sufficient confidence in (hardware can have malware!). Mind, if you're willing to trust the computer, you might trust its hard disk too.

There is a technical solution to bridge the gap between trusting a small chip and trusting a whole desktop or laptop computer. Some PCs have a TPM (trusted platform module) which can, amongst others, verify that only a known operating system can be booted. Trusted Grub supports TPMs, so with a TPM plus Trusted Grub, you can have the assurance that the kernel you're running is one that you have approved.

Note that the adoption of the TPM can work for or against you. It all hinges on who has the keys. If you have the private key for your TPM, then you can control exactly what runs on your computer. If only the manufacturer has the private key, it's a way to turn a general-purpose platform into a locked-in appliance.

  • +1 for the reference to a big potential pitfall of TPM (aka Treacherous Computing)
    – Eli Heady
    Nov 22, 2011 at 1:33
  • You give no actual solutions, just mention popular security-related phrases. What you say about a MITM attack is a threat that ignores the main idea of the OP's question: Using a checksum-verifying script that lets the system boot only if certain conditions are met. At that point, there would be no problem in verifying that the actual underlying hardware is what it should be, not a VM. Nov 22, 2011 at 8:52

The booted kernel resides in memory. You can make a script that will locate it in /dev/mem and, knowing the size, calculate and verify its checksum.

You can also have the whole HD encrypted, with no need of /boot partition and (almost) no way to modify the kernel. How? two ways I can think of:

  • Place your kernel on a CD, off which your computer will boot. This is not that difficult; some people reported using such setup several years ago - see the second post in this forum thread.

  • If your motherboard is supported by coreboot and has enough room to fit a minimal kernel, you could have encryption-enabled kernel on your BIOS chip. (I haven't had a chance to test, but I see no reason why this might not work.)

Edit: Notice that all these are just single steps towards "trusted" or "verified" boot (which Gilles rightly pointed to). The complete mechanism should also take into account what is happening at bootloader stage and how underlying hardware is identified. Have a look at how Google Chromium OS does this.

  • Will it work? I'm not sure; I don't know offhand whether the kernel modifies its code in memory after it starts. I do know that you can't verify a module that way, because the module is linked into the kernel (changing some addresses here and there) when it's loaded. Will it provide the desired security properties? No, see my answer. Integrity is tricky! Nov 22, 2011 at 1:09
  • It seems that you did not read my whole answer. The first paragraph, which you refer to, is only a direct response to what was really asked. The rest of my answer presents options similar to the method you've mentioned, but better, because they are secure against kernel modification (unlike a USB pendrive). Nov 22, 2011 at 9:01
  • @Gilles Forgot to '@' you in previous comment. Also, I've just checked what you were unsure of: did a dump of in-memory kernel image, then added a bunch of modules, made a second dump of the region, compared - same. You can use this. Nov 22, 2011 at 9:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .