Physical computer security in Linux - a discussion

Physical computer security is a topic. A while back I wrote an article:

This is a technical guide about Linux disk encryption using a passphrase that is saved to the local computer's TPM2 - This allows for a better security (compared to a non-encrypted disk) while reducing human interaction during system boot up. Encryption of data in-rest is a good thing.

However, keeping your disk encryption key in your TPM2 module is not without risks. It opens your computer to a different set of local access attacks in order to obtain your data. An attacker can replace your disk with a different one, and try to obtain the passphrase from your TPM2, or enter command-line parameters to your GRUB or inject additional steps in your boot process - all these would allow obtaining your keys from your TPM2, just like the normal boot process does, except that - not by the boot process, and not for the purpose it was designed for.

It is imperative to establish a chain of trust between each and every component throughout the boot process. When defining a protected and secure chain of trust, an attacker cannot successfully inject a boot step which was not pre-defined in advance, and trusted. This way - an attacker cannot obtain your data (at least not through using local access attacks, so this attack vector is mitigated) and other means are required.

Recently, I was preparing a follow-up on my above mentioned article, dealing with the remaining of the physical protection - establishing the chain of trust, starting at the BIOS, and ending at the successful run of a trusted initramfs, throughout all the steps in between. During this process, as I was investigating the feasible methods of keeping a system maintained in a correct manner (meaning - easy to manage as an admin, and not go into a whole hassle on every kernel/initramfs update), I came to a conclusion that Ubuntu Linux (aka - Canonical) implements a chain of trust I cannot fully trust to prevent hijacking and gaining physical access to my encrypted data.

Canonical's goal was to better enforce "Trusted Computing", but, as I see it, their chain of trust was lacking. I have written about it in the article below - not as a technical know-how, but more of a discussion and thoughts of the subject - as I was investigating their way of doing things, and possible alternatives to a boot chain of trust I can put my trust in:

I would love to hear some insights or thoughts you may have on my article. I'd like to understand that my view of Ubuntu chain of trust method is incorrect, and to understand why I should trust their workflow. Or, of course - I would like to see that my view is correct, and that you agree with it. You are most invited to read the above mentioned articles and share your thoughts of them (preferably - there)

I appreciate your feedback.