From the perspective of the corporation buying big amounts of computers from an oem, your users are employees, and it makes sense that you don't want them screwing with secure boot. Individual Consumers still have options.
The ARM thing is, however, a bigger deal.
Secure boot is great we just have to demand that we control the keys.
The solution to UEFI is to refrain from using it. Just use a classic BIOS.
If some Linux distribution cannot boot via a legacy BIOS (how difficult is that, really? we've been doing it for over 30 years), then it's not an OS worth using.
Relative to everything else BIOS software has not changed much in 30 years (ask yourself why; it does not need to), and only a couple of companies have a monopoly on nearly all BIOS software.
A BIOS does not need features. It does not need a shell and applications. It just needs to initialise hardware and launch a bootloader, and to be able to do this from a variety of media. That is, relatively, a very simple task. You want it to work everytime, with no fiddling.
UEFI is not giving you anything that is worth the hassle it can cause and the complications it can add to simply booting a device. It is not giving you more freedom.
Whatever the reasoning behind UEFI (maybe there is no compelling reason; that wouldn't be a first), UEFI is a recipe for disaster. Because MS is headed downhill, they will get desperate and will try anything to retain market share; and they have a history of using complexity and obscurity as a way of disincentiving many users from using Windows alternatives (e.g. Gates used the original BIOS strategically this way in the 80's).
UEFI is certainly not the path to "hardware and software freedom". It will not make things easier for any user who wants to use different OS's on a variety of HW. But it may be abused by MS who has immense influence on hardware manufacturers.
Stick with the old BIOS. Keep it simple.
Also, even if your distribution supports BIOS, that does not mean your motherboard does.
It is the principle of the matter. Paying that $90, when really there is little reason to on x86 (it would be more excusable on ARM), is the equivalent of saying "uncle".
Who the hell even needs this "feature"? Are we really so afraid of an "evil maid" attack? People who legitimately need it are a minority (some larger corporations and... paranoid people?) and can remove/add their own keys.
I assume some part of their contract with MSFT would prevent them from doing this.
Calling people paranoid that want security feature X is not productive.
European governments are using Trojans to track pretty small crimes already, and some people regularly change planes in charming environments like China. What you say applies to almost every security measure.
For some people, these may be sensible security measures. For most people, including myself, it's just plain old paranoia. So long as it is harmless, there is no problem with it.
Protecting the general public from a hypothetical evil maid that wants to swap out their kernel is not harmless if it means inconveniencing consumers^, and is frankly off the deep end. Some people need to worry about that, and the tools needed to protect themselves should be made available to them, but the general public really doesn't have to worry about it. Making people opt-out of it is nuts.
^ Yeah, it's not MSFT's consumers that are being inconvenienced, and I can't imagine OEMs are going to all of a sudden start caring about minority OS users out of nowhere after all of these years... Neither of those facts will make me refrain from futilely complaining on the internet.
(as a side note, I don't see how productivity is involved. What does "being productive" mean here?)
Umm - I guess "convincing" would have been the better word? :) If you blame people for demanding too much security, then it only makes Linux look bad and insecure in comparison to Windows, or at least that was my impression in this thread. I don't think that the threat is inherently less realistic than any of the other things we protect against - the problem is Microsoft's implementation of this particular security measure.
Correct me if I am wrong, but the evil maid attack needs a physically present malicious person. The vast majority of bootkits don't need this and can install undetectable malware across the internet.
This seems to like either a protection against a hyper-paranoid threat, or a bandaid on a larger problem.
How many security incidents is secure boot actually projected to prevent?
A few references to widespread bootkits:
Except for the boot signature, all of these could have been successfully implemented in the past and prevented everything you reference -- how on earth would an internet virus update the kernel or boot unless the kernel let it? but that wasn't the case.
There is no reason that secure boot would help in this respect.
If it gets to the point that secure boot is what saved you, then there was already a series of fairly disturbing errors. Layered security is good, but if it is really needed in a common case to this extent... what the hell is going wrong?
The way I see it, secure boot is like SSL, it stands as the last resort before giving up complete control.
Or how about we have it secure by default and allow people who presumably know what they're doing to turn it off or enroll their own keys or ones they trust because of their heightened knowledge? Are there really a lot of people who are able to partition their hard disk but unable to turn secure boot off? How does that compare with the number of people running Windows and vulnerable to malware and bootkits?
If the private key is public, it's not secure, there's barely a point, hence my question... That's why I find this all so amusing.
So for Arm you would still need a signed boot loader.