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.
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.