Sorry, this is not a valid answer - you can checksum the boot device as much as you like, but I have not seen any procedure that ensures that you know the correct checksum. What could have helped you is not just a checksum, but a signature used with dm-verity.
What I do on my laptop is:
* BIOS password, of course. Note that this also prevents the attacker from resetting or turning off Secure Boot.
* Secure Boot enabled, with my keys only (no Microsoft keys).
* No GRUB, I use systemd-boot (part of systemd) and UKIs signed with my own key. Although, as I don't dual-boot, this might be an unneeded step. In any case, with Secure Boot enabled, systemd-boot does not allow editing kernel command line arguments at all and so cannot trick my UKI into doing anything else than what it is supposed to do.
* The main SSD partition is encrypted (with the passphrase that I have to type).
* The USB storage driver is not in the initramfs, so the storage device found by the initramfs is guaranteed to be my internal SSD.
* The Secure Boot keys are stored inside that encrypted partition and are used to dynamically sign new sd-boot releases and UKIs. I guarantee that I don't sign anything except UKIs that ask for my SSD password, and any shell-out possibility is treated as a bug.
* There is a separate set of keys for signing the custom rescue media, which is also a big UKI.
This way, the attacker cannot boot anything other than my UKI (first, because of the BIOS password, and second, because Secure Boot won't allow anything else), cannot obtain a shell by running something before I enter the password, and, therefore, cannot clone or overwrite my disk.
Note that this setup has also been criticized as insecure ("you don't use TPM, so you can't be secure, it's a theorem"), but I don't understand this argument.
As for the hardware keyloggers, you are, of course, right.
