From: (Anonymous)
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.

-- Nix
From:
Anonymous
OpenID
Identity URL: 
User
Account name:
Password:
If you don't have an account you can create one now.
Subject:
HTML doesn't work in the subject.

Message:

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org


 
Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags