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
no subject
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