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(a)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
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|