On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé berrange@redhat.com wrote:
That's thinking about the problem from the wrong point of view. SecureBoot doesn't prevent an attacker from booting an OS that's different from what you installed, even without shim they could swap to a different Windows install. What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key.
I think you mistaken SecureBoot with a TPM measurement.
SecureBoot is indeed only about executing or not executing a code which is signed by a trusted key. Naturally if there are multiple trusted keys or a whole tree of signed firmwares, loaders, and operating systems, then from SecureBoot point of view, they are equivalent.
On the other hand, attesting that a system booted into the same state as yesterday is a different problem and can be achieved without any signatures. E.g. with TPM-measuring each executed piece of code and configuration data.
I can see where the misunderstanding comes from: The traditional TPM scenario requires the a user to establish the trust with TPM by seeding it with a new initialization vector. That's not practical in cloud computing where the user has no access to the hardware. Therefore CPU vendors came with a complicates structure of keys, derived keys. encrypted memory, enclaves inaccessible to a hypervizor etc. I don't know much about this. However, I believe that this security feature you are familiar to from the world of virtualization is not called SecureBoot.
-- Petr