Which is kinda funny on a laptop. If some authority told you to unlock a device and it did have a plausible deniability encryption system - no one is going to believe that anyway.
For a USB drive or a file, sure, feature. For a laptop, “duh, it’s encrypted” is going to be the first thing anyone considers. Not “well, I guess the laptop has no data on it at all!”
Metadata includes file names. If you have a file on your computer called proof_nsa_is_doing_illegal_stuff.pdf, that would significantly help a prosecutor trying to convict a wistleblower even if they can't get the file.
For servers that you need to unlock remotely, you will need to leave /boot unencrypted. But, for things like a laptop, grub has supported encrypted /boot for a while now (and it works well). But, the release versions still only support luks v1 (it was good enough for all those years, probably still fine for most folks mostly just worried about their laptop getting misplaced / stolen).
add to /etc/default/grub to enable encrypted /boot support:
GRUB_ENABLE_CRYPTODISK=y
After encrypting /boot, you don't need anything besides ensuring that the less than 2MB of unencrypted grub bootloader that is installed before the first partition on BIOS machines or into /boot/uefi on uefi machines is verified to ensure that 100% of the boot process is trusted (and all your data too since 100% of the disk is encrypted except for < 2MB of boot loader).
A simple way (if your threat model isn't mosad/nsa) is just checking a hash of this tiny bit of data whenever something sketchy has occurred with your laptop e.g., it is left unattended with airport security. Just boot from a thumb drive, and check the hash (it will only change if you e.g., change your filesystem type or grub gets patches). If OK, then boot is still trusted (at least what is on disk; if threat model makes you a possible target for hardware manipulation this nor Pottering's proposal will help you).
Nice if this simple check of less than 2MB could be automated, but not in a complex and fragile way that removes freedom from the nominal owner of the computer as Pottering is suggesting.
What does a laptop with a bunch of random data on its disk and a lot of evidence of use (grime, worn keys, etc.) let you deny that the same laptop with a generic Linux boot partition followed by random data does not let you deny?
Let's put it this way: say you want to prevent somebody from getting the data on a disk. Wouldn't writing random data over the entire disk be a good idea?
So have one drive with FDE and a USB drive with /boot but in no explicit way configured to boot the first drive?
Or maybe a better setup is an internal drive with /boot and a system stripped from sensitive files then somewhere in the drive an hidden partition (not sure how to avoid the vanilla OS overwriting the hidden partition), then you can either boot the vanilla OS or map the hidden partition and boot from it.
Huh, I thought BIOS/MBR required /boot to be on a partition at the beginning of the MBR and nowhere else, whereas UEFI allows it to be anywhere on the disk as long as its labeled with ESP.
So with UEFI, you just label /boot on USB as ESP. How does it work with BIOS/MBR?
That was an issue with older BIOS versions which also often didn't fully support LBA indexed sectors.
Any system with a UEFI BIOS that has 'CSM' (compatibility support mode IIRC) should support arbitrary placement of the /boot partition.
Today the main reason to put /boot early is for migrating to larger drives later, the start sector of many filesystems (including windows) can be left in place, and the size of the last partition, the data/system partition can then just be expanded.
I like to have each Linux distro on a standard type 83 partition if in BIOS mode, or its corresponding 0FC63DAF-8483-4772-8E79-3D69D8477DE4 GUID if in UEFI.
These are neutral dedicated storage designations for later EXTx formatting.
With Windows to be on partitions of BIOS type 07 or UEFI GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.
Once again neutral dedicated storage designations, for later NTFS formatting.
Each distro is entirely self-contained on its own single volume, no separate /usr /home swap or anything else.
This is analogous to a Windows install.
But as intended, bootfiles can function properly from many different storage locations.
In BIOS you will need boot files on a primary partition and it will need to be the primary which is marked "active" (bootflag 80 rather than inactive default 00). You will also only be allowed to have a maximum of 4 primary partitions in BIOS. But with correct bootfiles on an active partition you can boot to OS's that are on logical partitions too if you want to put them on your bootmenu.
In BIOS you can have a /boot folder on the same primary that your distro is on and it can boot solely to the distro on that primary (no boot menu appears), or you can have more than one bootentry on the GRUB or Extlinux bootmenu, which triggers the bootmenu to appear and then you can boot to any other partition on the menu whether primary or not.
Analogous to Windows in BIOS when the BOOT folder is on the same active NTFS volume as the OS folders. In BIOS Windows will boot Linux using a BOOTMGR entry pointing to a copy of the Linux volume bootsector, stored on the NTFS (or FAT as often seen when a commonly found "hidden" partition1 is used for Windows bootfiles) filesystem in the form of a file.
Windows will not address files on type 83 or 0FC63DAF-8483-4772-8E79-3D69D8477DE4 volumes so they are hidden from Windows naturally without having to possess the hidden attribute. These partitions will be sensibly handled in diskmanagement, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 will show as OEM rather than a blank table entry.
Linux can mount FAT (FAT32's preferred type is usually type 0C) or NTFS whether it is marked hidden or not. Type 1C is hidden FAT32, type 17 hidden NTFS. In BIOS Linux can boot Windows if you want to put it on your GRUB bootmenu.
It can be seen that you could have 4 primary partitions, each containing an independent Linux or Windows OS, with 4 specific boot folders, one dedicated to each OS on the same volume the OS is on. Whichever one of these partitions you designate with the bootflag will be the one that boots, and the other partitions if unhidden can then be mounted as ordinary storage volumes. You would never see a bootmenu and would have to change which primary has the bootflag in order to choose which OS to boot to.
This is good when you need to boot to something different and do a comprehensive backup of a working volume but in its static dormant state, whether bitwise or file-based backup.
Sometimes there are no spooks trying to cause mayhem, and the most reliable rapid backup & recovery methods need to be constantly rehearsed and revalidated foremost.
However, in any one (or more) of these BOOT folders on any of the primaries you can trigger the display of its multiboot menu simply by adding a second (or more) bootentry of your choice to its default boot configuration file.
You could even have identical full multiboot menus in identical BOOT folders on each volume, and even on an external bootable USB volume too.
This gets analogous to UEFI where you only use one /EFI/BOOT folder on a special C12A7328-F81F-11D2-BA4B-00A0C93EC93B GUID ESP partition (but if not found then the first FAT volume the firmware recognizes), formatted FAT32 and readable by all.
But in the EFI\BOOT folder there is just a .EFI file or 3 (like BOOTX64.EFI) which is what each OS install strategically renames its EFI bootfile as, which then points to its own specific \EFI\Microsoft or \EFI\debian ect. subfolder which takes it from there. The Microsoft subfolder will contain its bootmenu, better Linux distributions have it this way too (ie you can edit its GRUB bootmenu when booted to Windows because you can see it in the desired EFI\Linux subfolder), but some distros only link (during bootup) from their subfolder to their bootfiles on their EXT partition and can only be edited when booted to Linux.
Now in UEFI I have not found a way to get Windows bootmenu to boot Linux. There should be a BCDEDIT switch that should do this like there is with BIOS BOOTMGR. If Microsoft starts to get serious about interfacing Linux this would be the first deficiency they will correct, so we will know if that occurs.
It can be seen that Microsoft SecureBoot was developed in quite a stifling way when it comes to Linux. For instance if you need a live Linux distro to be bootable on any default PC which has Microsoft SecureBoot enabled, you definitely need to have a Microsoft-signed shim or something like that. Machine owner keys are good for all the top-secret operators and serious geeks but ordinary power users want things like that to just work with the same default Microsoft-signed key that Windows uses without having to insert custom keys into the mainboard firmware. The only key that's built into every modern PC is signed by Microsoft, simply because it's a PC not a MAC.
Often the Microsoft-signed Linux SecureBoot shim will be renamed to BOOTX64.EFI which is what the firmware is looking for and from there the next bootfiles are signed by the distro.
The problem is that not every Linux distro uses the same key/signature so there are some different shims, one from each major distro that overcame the SecureBoot obstacle by having a shim signed by Microsoft.
This really makes UEFI highly defective when it comes to running live distros or multibooting, compared to how usefuil the same electronics is when SecureBoot is disabled or in BIOS mode. Except for those PCs that actually can enable SecureBoot in BIOS mode, how thoughtful.
What's really needed from the author is fundamentally to get all distros onto the same shim first of all, so the Microsoft-signed spare keys for future Linux use built into the UEFI firmware do not all get blacklisted as fast in case events like that come along more often. In that case it's a lot more sensible to blacklist a single key for all distros rather than a bunch of keys at once because each major distro has a different one.
Then move on to address much further the deep security needs of the most sensitive users, whether they are using Microsoft-signed shims, or their own machine owner keys which negate the need for shims when they are in use.
> Possible with UEFI, not BIOS/MBR.
Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.