A few years ago, Naja Melan wrote a verifyBoot. Excerpt of readme:
verifyBoot helps you to automate the process of checking if your MBR and a partition have not changed. verifyBoot makes sha256 hashes, first of the entire partition, then of your MBR and every file individually on the partition to help to find out what has changed. Nowadays it has become reasonably trivial to have linux installed on an encrypted partition using dmcrypt or other encryption software. The usual procedure for system start-up implies for the bios to load the MBR of the boot device or the boot sector of a partition which then loads grub. Grub will load the kernel which will then take care of further booting and decryption of the encrypted system partition. The problem with this approach is that everything in the “/boot” partition is not encrypted, facilitating a rootkit attack. An attacker could make the user run a process with the required privileges before or during a moment when the boot-medium gets plugged into the running operating system. This would allow them to place a rootkit, but also to access to the unencrypted data which would probably be what’s at stake here in the first place, so this is not a very interesting scenario when considering the threat of a rootkit. The second option an attacker has when they can’t convince the user to run a rogue process is is to get physical access to the boot-medium. Since “/boot” is not encrypted, they can easily install a rootkit compromising everything on the system as soon as the user provides their pass-phrase. It is possible to considerably raise the bar of such an attack by installing one’s boot partition on a usb-stick that one carries at all time. This makes it hard for an attacker to obtain the unencrypted boot partition to compromise it. What do you do however when you go swimming, or when you get arrested or if you forget your usb stick somewhere. You could no longer be a 100% sure it wasn’t compromised. After you have been separated from your boot medium you should verify that it hasn’t changed. This is where verifyBoot comes in. It helps you to automate that process of verification. Note that you will need a safe system to run the verification test from. This could be a verified live system that you obtain from a trusted source for example. If the boot system has changed you will need to create a new one from a trusted system or use an encrypted backup copy to restore your boot partition before booting from it.
It is tied to MBR, and doesn’t work with GPT. It isn’t perfect, but it helps BIOS/MBR users with some vulnerability detection. It also seems like a feature the kernel should have…
Firmware Security 