So my pre-existing belief that Secure Boot is only useful for either preventing attacks or restricting users if its implementor can write perfectly bug-free code must be extended to note that the implementor also needs to have assumptions that all its developers can keep perfectly in mind and never violate, no matter how long ago they were set. Which is really just another way of saying the first thing, since violated assumptions are a common cause of bugs...
By extension, this feature is a waste of everyone's time: it will inevitably fall (via similar paths to those seen here, unless MS have a magic bug-preventing mechanism that none of the rest of us do) and when it does all that will be left of it is lots of annoying complexity that won't actually stop attackers but will just irritate people trying to use their "Secure" Boot devices like the non-secure ones they always had.
... sounds very much like all other boot-time firmware ever, really. Cruft layered on cruft layered on cruft, all useful once upon a time but rendered useless by the passing of years.
Early roots of trust are no more secure than the rest of our buggy software world
By extension, this feature is a waste of everyone's time: it will inevitably fall (via similar paths to those seen here, unless MS have a magic bug-preventing mechanism that none of the rest of us do) and when it does all that will be left of it is lots of annoying complexity that won't actually stop attackers but will just irritate people trying to use their "Secure" Boot devices like the non-secure ones they always had.
... sounds very much like all other boot-time firmware ever, really. Cruft layered on cruft layered on cruft, all useful once upon a time but rendered useless by the passing of years.
-- Nix