https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html
-Have you heard of reports of breaches using openSUSE or the likes?
-Can improper provisioning of TPM cause mainboard failure ‘TPM chip itself fails’, or something along this line?
Reading the article further (tired here now)… TPM PCR Brittleness
Locking devices to TPMs and enforcing a PCR policy with this (i.e. configuring the TPM key to be unlockable only if certain PCRs match certain values, and thus requiring the OS to be in a certain state) brings a problem with it: TPM PCR brittleness. If the key you want to unlock with the TPM requires the OS to be in a specific state (i.e. that all OS components’ hashes match certain expectations or similar) then doing OS updates might have the affect of making your key inaccessible: the OS updates will cause the code to change, and thus the hashes of the code, and thus certain PCRs. (Thankfully, you unrolled a recovery key, as described above, so this doesn’t mean you lost your data, right?).
When enrolling a recovery key it is generated and shown on screen both in text form and as QR code you can scan off screen if you like. The idea is write down/store this recovery key at a safe place so that you can use it when you need it. Note that such recovery keys can be entered wherever a LUKS password is requested, i.e. after generation they behave pretty much the same as a regular password.
I think this may have happened to a Lenovo m91p SFF I own. Does the openSUSE way support and enroll recovery keys in it’s way of use with TPM?
I use TPM and PCR measurement on Aeon, it generates the recovery key and QR code during install. It’s a MiniPC desktop attached to the side of my workstation, so not likely to be in a hotel room 
Seriously though, if someone has physical access, all bets are off…
Yes, I’ve had to re-enroll a couple of times, no data loss.
You can not trust TPM if you can not trust Secure Boot:
So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set.
From:
Hi, reviewing Secure Boot article above. Question, Is SELinux a form of one of the following technologies though not spoken of in the following paragraph (from secure boot article)?
If we run one of the distros that do not leverage technologies such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity) Management Architecture), then Secure Boot protected the boot integrity for basically nothing, because the security chain is broken by the operating system, and user data is at risk from possibly any tainted userland executable.
Even if Secure Boot is working correctly you still have to trust who/whatever organization is providing the software and other infrastructure doing that, also a malicious application can be signed, for an idea see supply chain attack and the XZ backdoor.
Personally I worry more about what comes in and goes out my computer but I did not spent time to look into opensnitch.