This appears to me as another nice argument for authenticated/trusted/TPM-based boot over secure/restricted boot.
In authenticated boot, you can test your boot chain a posteriori and decide at the end if it meets your security policy. In secure boot, you need to restrict the capabilities for reaching insecure system-state a priori and for every boot step regarding your security policy.
This also leads to being able to choose and switch policies in the first case, whilst in the second case you can have only one single policy forever.
Feel free to contact me on that topic if you'd like to discuss it further. Cheers, Andreas Fuchs at Fraunhofer SIT
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2013-12-04 09:35 am (UTC)In authenticated boot, you can test your boot chain a posteriori and decide at the end if it meets your security policy.
In secure boot, you need to restrict the capabilities for reaching insecure system-state a priori and for every boot step regarding your security policy.
This also leads to being able to choose and switch policies in the first case, whilst in the second case you can have only one single policy forever.
Feel free to contact me on that topic if you'd like to discuss it further. Cheers, Andreas Fuchs at Fraunhofer SIT