Encrypted disk without a separate “/boot”
When support for legacy grub (or grub1) was dropped for opensuse 13.2, one of the reasons was to make it easier to support encryption without a separate unencrypted “/boot” partition. Recent releases of grub2 have some support for accessing encrypted file systems, so it was mostly a matter of adding support to the installer.
I decided to test how that works. So I did a test install of opensuse 13.2 into an encrypted LVM, without a separate “/boot”. The Yast installer was happy with that. It did not complain that there was no “/boot”. So I continued through the full install.
There were no install errors reported. But it didn’t work. Instead, while booting, I got a grub shell. And the grub shell did not offer any commands related to crypto.
I tried again with Tumbleweed, in the hope that support had improved. The results were the same.
But then a thought occurred to me. My tests had been with UEFI and secure-boot. So I turned off secure-boot in the BIOS. And I used the “opensuse” entry from the boot menu (rather than the “opensuse-secureboot” entry). This worked. I was prompted for an encryption key by grub2. After providing the encryption key, the normal grub2 boot menu showed up. I then booted into the install system. I had to provide the encryption key a second time, though that turned out to be less annoying than I had expected.
What had happened was this:
- The installer had generated a grub2 boot binary with the needed encryption;
- When using secure-boot, a static grub2 boot binary is used. It cannot be dynamically built, because it needs to be signed with the distro key. So, booting with secure-boot, or with the “opensuse-secureboot” EFI entry gave me a grub2 boot binary without crypto support.
- When I turned off secure-boot and used the plain “opensuse” boot entry, I was booting with the dynamically generated grub2 boot binary that did have support.
This was reported as bug 917427. It is now fixed, at least in testing. The fixed version is not in the repos at present. I’m hoping that it will be in Tumbleweed soon, and perhaps in 13.2. The fix was to include crypto support in the statically built grub2 boot binary.
The most obvious benefit is that disk partitioning is easier if you don’t need to provide “/boot”.
Another benefit, perhaps more important, is that the “initrd” is now inside the encrypted space so better protected from tampering. However, somebody could still tamper with the grub2 boot binary. Secure-boot protects against that, but is not yet available until those fixes are pushed to the repo. And, of course, there is still always the risk that somebody could install a trojan UEFI firmware. So nothing is completely secure.
Still, I see this as a security improvement. Or, at least, it will be when the fixes are pushed to the repos to make them generally available.
The main downside is the need to enter the encryption key twice. The first of those is for grub2 to access its menus, and the second is for the kernel to access the file systems.
Another disadvantage is that, with the increased complexity, there is a greater risk of failure and a greater difficulty in recovery.
Where can this be used?
I am mostly guessing here. My tests have been with UEFI. From what I have seen (including online discussions), this is possibly also available for legacy booting. But, in that case, I’m guessing that it only works when grub2 is installed in the MBR. And even then, I’m guessing that it only works if the first partition begins at sector 2048 on the disk (rather than sector 63 as was the older partitioning practice.
My guess is based on the need for grub2 code to contain the decryption capabilities. That takes some space. With the first partition at sector 2048, there is around 1M of space for that code, which should be sufficient.
Similarly, it probably works with GPT partitioning where there is a separate BIOS Boot partition and grub2 is installed in the MBR (and uses that BIOS boot partition).
Note that I have not tried any of these. My only tests have been with UEFI.