Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any Linux boot loaders supporting full disk encryption (a la TrueCrypt). I know there was work towards adding encryption support to GRUB2, but this does not seem to be ready yet. Any other options?

(Note that I am really referring to full disk encryption here -- including /boot)


Most of the answers describe a setup where /boot is not encrypted, and some of them try to explain why an unencrypted /boot should be OK.

Without getting into a discussion on why I actually need /boot to be encrypted, here is an article that describes exactly what I need, based on a modified version of GRUB2:

The problem with this is that these modifications apparently are not supported in the current GRUB2 codebase (or maybe I am overlooking something).

Hope this helps to clarify the question.

share|improve this question

migrated from stackoverflow.com Jan 27 '12 at 1:30

This question came from our site for professional and enthusiast programmers.

yes, there is an excellent howto here: wiki.archlinux.org/index.php/… – ebal Nov 14 '10 at 20:04
up vote 13 down vote accepted

I think the current version of GRUB2 does not have support for loading and decrypting LUKS partitions by itself (it contains some ciphers but I think they are used only for its password support). I cannot check the experimental development branch, but there are some hints in the GRUB page that some work is planned to implement what you want to do.

Update (2015): the latest version of GRUB2 (2.00) already includes code to access LUKS and GELI encrypted partitions. (The xercestch.com link the OP provided mention the first patches for that, but they are now integrated in the latest release).

However, if you are trying to encrypt the whole disk for security reasons, plese note that an unencrypted boot loader (like TrueCrypt, BitLocker or a modified GRUB) offers no more protection than an unencrypted /boot partition (as noted by JV in a comment above). Anybody with physical access to the computer can just as easily replace it with a custom version. That is even mentioned in the article at xercestech.com you linked:

To be clear, this does not in any way make your system less vulnerable to offline attack, if an attacker were to replace your bootloader with their own, or redirect the boot process to boot their own code, your system can still be compromised.

Note that all software-based products for full disk encryption has this weakness, no matter if they use an unencrypted boot loader or an unencrypted boot/preboot partition. Even products with support for TPM (Trusted Platform Module) chips, like BitLocker, can be rooted without modifying the hardware.

A better approach would be to:

  1. decrypt at the BIOS level (in motherboard or disk adapter or external hardware [smartcard], with or without a TPM chip), or
  2. carry the PBA (preboot authorization) code (the /boot partition in this case) in a removable device (like a smartcard or an USB stick).

To do it the second way, you can check the Linux Full Disk Encryption (LFDE) project at: http://lfde.org/ which provides a post-install script to move the /boot partition to an USB memory, encrypting the key with GPG and storing it in the USB too. In that way the weaker part of the boot pathway (the non-encrypted /boot partition) is always with you (you will be the only one with physical access to the decrypting code AND the key). (Note: this site has been lost and the author's blog also disappeared, however you can found the old files at https://github.com/mv-code/lfde just note the last development was done 6 years ago). As a lighter alternative, you can install the unecrypted boot partition in an USB stick while installing your OS.

Regards, MV

share|improve this answer
Decrypting at the BIOS level would be a very good solution indeed (I have considered this as an option)... – Grodriguez May 19 '11 at 15:49
I don't know any working implementation, but EFI/UEFI has the option to include a custom EFI Boot Manager to replace a common boot loader, maybe adding a decryption layer to decrypt the data (of course then you'll need an EFI platform). Or maybe some of the project related to CoreBoot (ADLO, SeaBIOS, OpenBIOS, etc.) can be modified to do that. Just ideas. – MV. May 24 '11 at 8:40
Just to add more information about the weakness of using a non-encrypted /boot partition (but it also apply for an non-encrypted boot loader): twopointfouristan.wordpress.com/2011/04/17/… (how to modify the boot partition in 10 minutes of physical access, to retrieve the mount passphrase plus any other file in the encrypted partition) – MV. Jul 21 '11 at 2:16
@MV.: Thanks. I may test it myself and add an answer here with more detailed steps to use encrypted /boot partitions with GRUB2. – Peque Feb 20 '15 at 10:11
@에이바 : no, that is related (using LUKS with a TPM) but is not the same project previously hosted at lfde.org (which now is a site about an aeroclub). – MV. Apr 2 at 1:16

Make your Initial RAMdisk, and /boot folder not use encryption.

This will bring up a "minimal" kernel, with drivers and support to switch to the "actual" root filesystem which is encrypted.

Before you claim "this is a hack" - remember - most (if not all) Linux distros boot this way today by default. This explicitly allows your system to boot and load your root FS, using modules that it needs to load from a filesystem. (Sort of a chicken-and-egg problem). Like for example, if your root filesystem was on a hardware RAID volume, and you needed to load it's driver before you could mount your root FS.

share|improve this answer

I reviewed the link you posted - although there is no boot partition, there is still an unencrypted boot loader on the hard disk which could be accessed and compromised using an evil maid attack. I've been looking into a similar setup, in which there is no unencrypted data on the hard disk, but so far I've only come up with running a boot loader from a removable drive.

share|improve this answer
Yes, there is still an unencrypted boot loader. This would be acceptable for me. – Grodriguez Apr 28 '11 at 19:00
The evil maid can infect the boot loader to do a fake password prompt to fool you, then just load the unencrypted trojanized kernel. Encrypting the kernel gains very little without encrypting the boot loader. – Skaperen Jan 27 '12 at 2:56

I believe most of them do, what you need is instruction on how to install the OS with encrypted HD in the first place.

Ubuntu has a nice page with instructions on making encrypted partitions, LMVPs, folders etc, just google your distros version of that...

share|improve this answer
Most Linux distributions, including Ubuntu, include some sort of support for encrypting partitions, but they require /boot to be unencrypted. What I'm looking for is a boot loader that can handle a completely encrypted disk. – Grodriguez Nov 14 '10 at 23:47
At least some part of the bootloader needs to be unencrypted, otherwise the CPU couldn't run it. Is there any particular problem you have with leaving /boot unencrypted? – Baffe Boyois Nov 15 '10 at 4:27
The boot loader and /boot are different things. I am looking for a boot loader than can boot a fully encrypted disk. TrueCrypt can do that for Windows, but not for Linux. – Grodriguez Nov 15 '10 at 7:11
The difference is that the windows bootloader is contained in the mbr itsself while on linux the mbr just links to the /boot files necessary. – J V Nov 15 '10 at 9:30
"Pre-boot authentication is handled by the TrueCrypt Boot Loader, which resides in the first track of the boot drive" - aka, on windows it creates a mini-/boot. Again, grub itself is contained in /boot, the mbr is only 512 bytes, not enough to store a decryption algorithm. However it's done, a portion of the hard drive must be supplied unencrypted. You might be able to start grub on an encrypted partition from a bootloader on a completely different one but that would require some seriously messy code... – J V Nov 15 '10 at 9:43

No, I think there are not.

Do you really need to encrypt /boot? I suspect not. The rest of the filesystem can be encrypted by normal Linux software which resides on an initramfs in /boot and prompts the user accordingly.

share|improve this answer
Yes, I need to encrypt /boot. Everything must be encrypted except for the boot loader itself. – Grodriguez Nov 15 '10 at 9:59
Please explain why you believe there are no bootloaders supporting full disk encryption. – this.josh May 18 '11 at 17:58
@Grodriguez: if you consider /boot to be part of the boot loader, then everything is encrypted - all binaries used at runtime, all user data, etc – MarkR May 19 '11 at 14:00
As noted in a comment on another answer: I know that there must always be "something" that is not encrypted -- I just need this "something" to be the boot loader (MBR + boot sector), instead of a /boot partition. – Grodriguez May 19 '11 at 15:48

You seem to be asking for something that is impossible to do and comparing it to a Windows solution which hides the implementation from you but in reality is doing the same thing Linux is doing.

The closest solution that I can think of is to use a hard drive which implements a security password and encryption. Some of the Thinkpad laptops use these hardware solutions.

share|improve this answer
Sorry, but I don't see why this should be "impossible". The article I link to in my question proves that it can be done. A proof of concept was implemented using a modified version of GRUB 2. I know that there must always be "something" that is not encrypted -- I just need this "something" to be the boot loader (MBR + boot sector), instead of a /boot partition. – Grodriguez Nov 15 '10 at 19:58
@Grodriguez: Your requirement makes no sense. Is your requirement met when using a virtual machine inside another OS? If so, then boot OS one, decrypt the drive and launch the VM. – Zan Lynx Nov 15 '10 at 21:14
Have you actually tried to read the article I linked to? The fact that you don't understand the requirement does not mean that "it makes no sense". I have valid reasons for this (which I don't want to get into). – Grodriguez Nov 16 '10 at 7:54
The article makes it clear in paragraph 3 that it does not improve the situation. So it makes no sense to me to follow the rest of it, which focuses on how to set it up, rather than how it works. Think about what is going to tell you that I have replaced your kernel, or the whole /boot, with my own (when acting as evil maid). – Skaperen Jan 27 '12 at 3:01

The answer is hinted at by the article. "This is now possible with extensions to the next generation GRUB2 bootloader, which has been patched to support not only" and "we wish to install our new luks enabled grub2 image later on" and "Now we compile the LUKS-enabled GRUB2 source." It seems there is an patch or extension you need to get and include with GRUB2, or a forked GRUB2 source.

share|improve this answer

Grub2 version 2.02~beta3 can do a lot things that Grub2 version 2.02~beta2 can not do, tested by me:

  1. Boot using Super Grub 2 disk
  2. Type 'c' key to go to command line
  3. Type commands to mount encrypted partition i want
    • insmod luks
    • cryptomount (hd0,#) // where # represents the encrypted partition
  4. Type the passphrase and type some commands more
    • multiboot (crypto0)/grub/i386-pc/core.img
    • boot

That will load another Grub2 that is inside an encrypted partition, an evil mad attack has no sence in here... i am booting from a CD (read only medium), then mounting an encrypted partition (with not the passphrase how dare can anyone inject anything!), then booting from inside encrypted partition and loading a Grub2 with its own menu, etc.

Note: Such Grub 2.02~beta3 boot (i use Super Grub 2 cd) can be on a USB stick, USB HDD, etc.

Warning: Grub2 version 2.02~beta2 can not do the same since has some BUGs (that seem to be fixed on Grub2 version 2.02~beta3) related to command cryptomount...

beta2 bugs, i talk about, are:

  1. It does not really mount the encrypted partition, so it does not let you access (crypto0)/*
  2. If there is more than one encrypted partition, using cryptomount -a only asks for one passphrase
  3. After running cryptomount one time it it is runned again does nothing

on beta 3:

  1. It really mounts encrypted partition and let you access files through (crypto0)/* or (crypto1)/* etc if more than one mounted at same time
  2. It asks for each passphrase (one per encrypted partition)
  3. It allow you to run it as many times as you need, you can mount one, then another, etc.

Side note: I did not figure how to unmount them, except reboot or boot another or same grub2 / other bootloader, etc.

Hope this helps to clarify things, and hope Grub2 version 2.02~beta3 will be integrated on LiveCDs so all we can install it without need to compile it by our selfs.

P.D.: With Super Grub 2 disk i can not see any way to install Grub2 version 2.02~beta3 onto the MBR /boot partition etc.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.