From 825c2ce63be498d4cc9d6ef73749c148975d90f4 Mon Sep 17 00:00:00 2001 From: TommyTran732 <57488583+tommytran732@users.noreply.github.com> Date: Sun, 25 Jul 2021 11:10:54 +0000 Subject: [PATCH] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 704e377..6548f2e 100644 --- a/README.md +++ b/README.md @@ -58,7 +58,7 @@ The partition layout I use rallows us to replicate the behavior found in openSUS | 16 | @/var_lib_AccountsService | /var/lib/AccountsService | Encrypted BTRFS (nodatacow) | | 17 | @/cryptkey | /cryptkey | Encrypted BTRFS (nodatacow) | -### LUKS1 and Encrypted /boot (Mumbo Jumbo stuff for anyone who's wondering why) +### LUKS1 and Encrypted /boot (Mumbo Jumbo stuff) This is the same setup that is used on openSUSE. One problem with the way Secure Boot currently works is that the initramfs and a variety of things in /boot are not validated by GRUB whatsoever, even if Secure Boot is active. Thus, they are vulnerable to tampering. My approach as of now is to encrypt the entire /boot partition and have the only that is unencrypted - the grubx64.efi stub - validated by the firmware. Ideally, I could use GRUB's GPG verification for the initramfs and its configuration files and what not, but then I need to create hooks to sign them everytime they get updated (when a new initramfs gets generated, when grub-btrfs.path gets triggered, when grub gets updated and its config files change, etc). It is quite a tedious task and I have yet to implement or test this out.