Yes, if you have some means of performing attestation then this attack can be identified. But you need some mechanism for performing that attestation, which is a far from solved problem.
The policy case is actually an interesting one. The only policy imposed by Secure Boot itself is the firmware→bootloader handoff. The bootloader is free to impose any policy it wants, and in fact Shim takes advantage of that - it transitions the root of trust from the firmware keys to a separate key database. As long as you're willing to put up with some bridge code, you can impose any policy you want.
Power management, mobile and firmware developer on Linux. Security developer at nvidia. Ex-biologist. Content here should not be interpreted as the opinion of my employer. Also on Mastodon and Bluesky.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2013-12-04 07:58 pm (UTC)The policy case is actually an interesting one. The only policy imposed by Secure Boot itself is the firmware→bootloader handoff. The bootloader is free to impose any policy it wants, and in fact Shim takes advantage of that - it transitions the root of trust from the firmware keys to a separate key database. As long as you're willing to put up with some bridge code, you can impose any policy you want.