On Tue, Jun 28, 2022 at 01:12:25PM +0200, Petr Pisar wrote:
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.
Well actually I was really referring to the combination of the two. SecureBoot makes the use of TPM more practical / straightforward by avoiding the need to tie the policy to measurements that change on every software update, instead you can tie to a measurement associated with successful secure boot.
With regards, Daniel