updates to blog post having now tried this

1 files changed, 16 insertions, 22 deletions

diff --git a/blog/entry/evilmaid.mdwn b/blog/entry/evilmaid.mdwn
index 0864173..d640d2b 100644
--- a/blog/entry/evilmaid.mdwn
+++ b/blog/entry/evilmaid.mdwn
@@ -69,9 +69,8 @@ improve security!
 # Something better
 
 Recent GRUB is able to decrypt partitions itself.  So `/boot` can
-reside within your encrypted root partition.  Apparently, GRUB's setup
-scripts are smart enough that you can switch over to this in just a
-few steps:
+reside within your encrypted root partition.  GRUB's setup scripts are
+smart enough that you can switch over to this in just a few steps:
 
 1. Move contents of `/boot` from USB drive into root partition.
 2. Remove/comment `/boot` from `/etc/fstab`.
@@ -79,8 +78,6 @@ few steps:
 4. `grub-install /dev/sda`
 5. `update-grub`
 
-(haven't tried this yet!)
-
 It's still true that there must be unencrypted code that knows how to
 decrypt the root partition.  Where does that go?  `grub-install` is
 the command that installs that code; where does it put it?  The
@@ -108,30 +105,27 @@ the BIOS boot partition.
 
 My proposed solution, pending UEFI Secure Boot, is to use BIOS boot
 with a MBR partition table, keep `/boot` in the encrypted root
-partition and `grub-install` to the USB drive.  Then set the laptop's
-boot order to never try to boot from the HDD, only from USB.  (There's
-no real advantage of GPT with my simple partitioning setup but I think
-that would also work fine.)
+partition and `grub-install` to the USB drive.  `dpkg-reconfigure
+grub-pc` and tell it to never `grub-install` to anything.  Then set
+the laptop's boot order to never try to boot from the HDD, only from
+USB.  (There's no real advantage of GPT with my simple partitioning
+setup but I think that would also work fine.)
 
 How does this solve the various issues I've raised?  Well, the amount
 of code on the USB drive is very small (less than 1MiB) so it is much
 less likely to require manual updates.  Kernel updates will modify
-`/boot`; only bootloader updates need run `grub-install` and modify
-the post-MBR gap, but these are very infrequent.
+`/boot`; only bootloader could require me to manually run
+`grub-install` to modify the contents of the post-MBR gap, but these
+are very infrequent.
 
-Further, upgrades won't break because the USB drive is not mounted.
-Glancing at the `postinst` maintscript of the grub-pc package reveals
-that it will call `grub-install` on the physical drive where `/boot`
-is located, AFAICT, so it will install to the laptop HDD's post-MBR
-gap.  Fine.  That code will never get run, because the laptop is
-configured never to boot from its HDD (and cracking *that* is a
-hardware modification beyond the evil maid, that we're not trying to
-protect against).  As a nice bonus, the USB drive's single FAT32
-partition is now usable for sneakernet.
+Of course, the BIOS could be cracked such that the laptop will boot
+from the HDD no matter what USB I have plugged in, or even only when
+some USB is plugged in, but that's a hardware modification beyond the
+evil maid, against which we are not trying to protect.
 
-Haven't tried any of this yet.
+As a nice bonus, the USB drive's single FAT32 partition is now usable
+for sneakernet.
 
 [ArchLinux wiki has the answer]: https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions
 
 [drives partitioned with recent tools]: https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-instead-of-63
-