That’s not at all what this about. Poettering has given quite a few talks about this subject, that being Linux boot chain verification and integrity.
One of the core concepts is measured boot. The TPM on your CPU measures the values of various pieces of software in the boot chain. If a measurement does not match, then the system will not boot because it could be compromised.
And unlike secure boot, this is a decentralized system. It’s not some corporation like Microsoft saying “this software is signed with this approved key, so it may boot”. It’s your own system checking the software and recording the expected value so that when you boot up, it checks again to make sure they match.
It’s not about apps asking doing things like DRM checks or anything like that. In fact, it can’t. GrapheneOS implements a system just like this to ensure the OS has not been tampered with.
The problem is that this value can be compared to a list of “allowed” values. Therefore it opens the gate to creating software that would require only certain “whitelisted” systems to run it. Such list can be easily updated automatically once those “whitelisted” systems update. Therefore an argument “updates would break it” do not actually work.
This is precisely how play integrity works on android. And Poettering intensions do not matter much. His system can be used like that and therefore it will be used like that.
The problem I see with that is that these values are far from regular. At the very least, the TPM will be checking the Linux kernel, bootloader, BIOS firmware. Any update to those will result in different measurements. And it’s not just the version that matters, but also the configuration. And there’s more things the TPM can measure, like connected hardware devices.
To reiterate, it’s not the case that the distro provides a hash of what the measurement should be. When you install, the actual software gets installed gets measured and recorded. That first measurement is automatically trusted, assumed to be good. It’s unique to your machine. Your machine will only boot so long as those measurements match. Those measurements only get updated when measurements are re-run, which is done after system upgrades.
Creating an allow list that works for most people would be next to impossible. The Secure Boot approach is much more suited for this task. I can only see this TPM allow-list approach working on corporate machines with controlled hardware and software updates. But at that point, using a custom secureboot key is easier and less liable to break.
That’s not at all what this about. Poettering has given quite a few talks about this subject, that being Linux boot chain verification and integrity.
One of the core concepts is measured boot. The TPM on your CPU measures the values of various pieces of software in the boot chain. If a measurement does not match, then the system will not boot because it could be compromised.
And unlike secure boot, this is a decentralized system. It’s not some corporation like Microsoft saying “this software is signed with this approved key, so it may boot”. It’s your own system checking the software and recording the expected value so that when you boot up, it checks again to make sure they match.
It’s not about apps asking doing things like DRM checks or anything like that. In fact, it can’t. GrapheneOS implements a system just like this to ensure the OS has not been tampered with.
The problem is that this value can be compared to a list of “allowed” values. Therefore it opens the gate to creating software that would require only certain “whitelisted” systems to run it. Such list can be easily updated automatically once those “whitelisted” systems update. Therefore an argument “updates would break it” do not actually work.
This is precisely how play integrity works on android. And Poettering intensions do not matter much. His system can be used like that and therefore it will be used like that.
The problem I see with that is that these values are far from regular. At the very least, the TPM will be checking the Linux kernel, bootloader, BIOS firmware. Any update to those will result in different measurements. And it’s not just the version that matters, but also the configuration. And there’s more things the TPM can measure, like connected hardware devices.
To reiterate, it’s not the case that the distro provides a hash of what the measurement should be. When you install, the actual software gets installed gets measured and recorded. That first measurement is automatically trusted, assumed to be good. It’s unique to your machine. Your machine will only boot so long as those measurements match. Those measurements only get updated when measurements are re-run, which is done after system upgrades.
Creating an allow list that works for most people would be next to impossible. The Secure Boot approach is much more suited for this task. I can only see this TPM allow-list approach working on corporate machines with controlled hardware and software updates. But at that point, using a custom secureboot key is easier and less liable to break.