I have long advocated for disabling tpm in bios, uefi-boot raw dm-crypt to even get grub much less init. This is also how I have done encrypted disks in the cloud using dropbear ssh as an initram shim for key/pass entry. Bios boot pass is annoying but required. Watch your acess/auth logs. Run a HIDS. Isolate your procs and especially their network comms. Security is an onion, not that most c-suites have any idea thes…
if security is an onion, why do you advocate for throwing the baby out with the bathwater?
So to double check my understanding of this article and the linked one that led to it[1], the issue is: 1. the TPM does not require a password to get the decryption keys 2. bootup decryption passwords are checked by code , before asking (using?) the TPM's data (passwordless, because the bootup code is trusted) 3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data…
On further reading and wondering what some of these terms / tools are: since this is describing a system with un-attended decryption, it seems like it literally requires passwordless access to the disk encryption keys. If that re-reading is correct: yeah, there's not much choice but to put all hope in your code + the TPM, since you essentially can't wait for a password. You get what you pay for in that case - no pass…
Nah, I'm doubting myself more here as time passes.
If it's meant for unattended booting, why/how is there a password?
This smells more and more like an extremely poorly thought out system that allowed a bug to compromise the system.
What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?
Only rolling distros should be shipping mid-release cycle updates that break libc compatibility. It's not a normal thing for release-based distributions where userspace userspace compatibility is nearly assured during a release.
Compatibility does not need to break to require a restart of a process. Linux does not have a mechanism that tells processes to reload their shared libraries when they are modified on disk. When a .so file is updated on disk, for example a minor update for a security vulnerability, all processes using that library need to be restarted to utilize that new update. If you're not restarting processes on these upgrades, you are not getting their benefits.This is why tools like dnf-tracer-plugin exist, but it's often just as easy to reboot, especially if you built your systems to be fault tolerant.