On Wed, Dec 5, 2018 at 1:20 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Javier and Peter (added to the Cc) have been working on making > full-disk encryption storing the secret in the tpm work. > > This is what Windows with bitlocker does and what most smart phones > do now (more or less). Is this broadly supportable? a. Macs don't have TPMs b. Windows laptops have TPM 2.0 which I can't get to work on Linux (works fine on Windows 10). https://bugzilla.kernel.org/show_bug.cgi?id=185631 c. Can a TMP be reliably shared by both Windows and Fedora in a dual boot configuration? Whatever we're going to do by default needs to be broadly supported. And also we need to define broadly supported. Is leaving 20% behind acceptable? What's the fallback for them, and then why is that fallback not good enough for everybody else by default? > The tpm hashes all these hashes together and when the kernel wants to > access the encrypted root filesystem, it asks the tpm for the key, > if all the hashes together match what the tpm expects it will give > the key. This means that even if someone steals the entire laptop > he cannot modify anything, the rootfs is crypted so it cannot be > modified without the key and everything which comes before it is > hashed so it cannot be replaced either. This leaves the attacker > essentially stuck at the gdm login prompt. An advanced adversary > will certainly be able to find a way around this, but it is a good > level of security to start with. I don't understand. If merely booting unlocks the encrypted volume, the main point of FDE is obviated, which is securing data at rest. They can't modify any of the binaries in the measured boot chain, but they can read/copy, modify, and delete files I care about. I must be missing something. Even Bitlocker requires a user PIN at least to unlock the volume. macOS on hardware with T2 securing the encryption key likewise still requires a user to authenticate themselves with a passphrase. > On top of this we could do what Ubuntu does and encrypt home directories > at the filesystme level using the password the user uses to login to > protect/unlock the key for this. The downside of this is that all the file > metadata (filename, size) is not encrypted, but the contents is and > this would come *on top of* the full disk encryption using the tpm. > The advantage of using filesystem level per file encryption this way > is that it avoids the diskspace problem entirely. fscrypt does encrypt filenames. > FWIW I think that putting the entirety of gdm in the initrd is a bad > idea, esp. since we rely on firmware calls to load the initrd and > some firmwares are very stupid doing this sector by sector making > initrd loading quite slow already making the initrd huge will make > this problem much worse. I can't imagine it has to be that big. macOS has base "chooser" window UI, with smooth rendering and animations, used in three contexts: as the boot manager built into the firmware, as the login window built into the bootloader when FileVault 2 is enabled, and the login window when FileVault 2 is not enabled. Meanwhile, on my 2016 HP laptop, Windows 10 cold boots to a login window in 5 seconds flat. Fedora on that same laptop takes 17 seconds to get to a login window. Startup finished in 1.346s (kernel) + 2.484s (initrd) + 10.928s (userspace) = 14.759s That's about 9MB/s reads from an NVMe drive that does file system scrubs at 1400MB/s. So why is the kernel/initrd load so much slower? Firmware? Why is Windows so fast? Are they not depending on the firmware to load their image and instead use better code in their bootloader? I know they're not processing a boot like we are, they're in effect restoring a hibernation image based on system state at the login window, so they just read in a memory dump. Fedora gets hammered by an inherently disk and cpu intensive boot process because it's interpretive, hence 11s userspace. I don't know how much user data leaks in /var and what can be done about that (is it a bug, and the application should use ~/.var instead?) But I'm willing to bet there's some leakage in swap, so whatever plan should decide to either drop swap entire or configure it to be encrypted with a random key during startup (which of course makes it incompatible with suspend-to-disk). -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
