If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.

And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.

I mainly encrypt in case of theft, /boot contains nothing valuable. / contains a lot of information about my configuration, and installed packages, as well as the key to /home

Yeah, encrypting for theft or so you have piece of mind while the machine is off but in sight is a completely valid use case.

It all depends on your threat model. In the case someone is taking the machine from me while it is off (ie: most theft or legal problems), I have a chance given FDE.

In case someone has physical access to the machine without me around, I have little to no chance, no matter what I do.

A threat model which includes an attacker having potential physical access to a machine to perform an evil maid or other blackbag cryptanalysis is a threat model which is very difficulty to accommodate, and indeed replaced boot files are just the start of your problems.

A threat model without this however, has no reason to necessitate secure boot.

As such, I see no gain in using UEFI or SecureBoot as this guide outlines. It worries me that the author didn't consider a realistic threat model when writing this guide.

This guide also suggests:

> Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk.

So it's highly confusing what sort of threat model the author had envisioned this to be written for.