Ah we're having yet another Secure Boot discussion. Well if someone could explain to me how it makes things more secure than a bios password and disabling boot from anything but the hard disk, I would be educated. And if you don't lock the bios, you can disable secure boot, or make an exception.

Mandatory and unable to disable would be a different problem, like on Windows RT on ARM tablets.

Signing your own certificates and keeping the Windows certificates seems possible for now, but it seems clear to me that there has always been an agenda here to be anti Linux, and like so many other losses of liberty it is justified by a false claim of increased security.

But that is what MS is doing. They are making the disable switch optional.
Agreed. The quote in my sig fits well

Simply put if you, for example, executed something with a root-privilege exploit on your system and the bootloader and/or kernel (depending upon implementation) were modified the system would warn you of this and not boot. Without "secure boot" you would boot your system and be none the wiser.
There are real security reasons fro "secure boot" and the like and these concepts have been thrown around for decades with lots of people suggesting things in this vein. Just because M$ is using this as an excuse to be awkward does not mean the concept is completely without merit.

I'm not an expert on the matter and I haven't so far had the misfortune of using a computer with secure boot, but as I understand it, this technology protects only against a certain type of malware that composes only a fraction of all the malware found out there (boot malware, or whatever its name is). If the alleged protection it provides is an excuse for hardware manufacturers to prevent Linux and other OSs from running on their systems, then the benefits for us -- the end users -- are of negligible interest.

As for me, I'll try to avoid secure boot, or at least I'll make sure it can be disabled when I have to buy a new computer. If I'm paying for something I must have the right to do whatever I want with it, as other poster here said before.

Again, thank you all for your inputs :)

So finally, even if I have Secure Boot enabled and a 100 clean kernel, once my OS has booted I'm back in my old world where I just have to hope that my browser or pdf-plugin or any other SW I use for online banking hasn't been corrupted by malware, right?

Indeed, it's just another layer of security. Theoretically, also, since your OS (for example Ubuntu or Red Hat) installer disk was verified with a checksum, your bootloader and kernel are signed and you get all your software from the repositories (again, theoretical world) the attack surface is suddenly much smaller and relies only upon exploits and not somehow tricking you into installing something. Then you have something akin to iOS which, while I don't like using it, is likely a whole lot more secure, when used by a novice, than an average Windows or Linux PC. This, to my mind, is the kind of vision that "secure boot" was designed to move towards. And, as I mentioned, the concept isn't new and certainly isn't an M$ one.
Sadly M$ can't help using any feature to make things more difficult to avoid their products. This, to my mind at least, is the issue with "secure boot". As a feature it's a potentially decent idea and while it could be switched on, off or have keys added it was potentially a good thing for some Linux users, even. However, when implemented badly and, now, with the threat of being on by default with no facility to add more keys it becomes a real issue.
For what it's worth I have two laptops, from different manufacturers, both with Windows 8 installed and both had secure boot enabled. I was able to switch off secure boot and still have Windows 8 boot on both [and Windows 10 on the one I tried] -- I currently have dual-boot just using BIOS switching on one and this one uses GRUB. So, at present at least, manufacturers don't seem to be making things difficult in any way for Linux users. Hopefully I'll have a play in the next few weeks to see whether/how Linux can be installed with "secure boot" enabled. I just mention this since when I first heard of "secure boot" and UEFI I was dreading buying a new machine and now I have no idea what the fuss was about -- thanks to both hard-working Linux developers and sensible hardware manufacturers.

If it's easy to turn off secure boot, the boot isn't secure. Using hardware jumpers, or in the case of a laptop, a switch that requires a screwdriver to get access to, is *fine*. It's easy enough for anybody who really cares, and hard enough to not do unintentionally while requiring true physical access. Flip those to set the cert store into mutable mode, install keys, flip back, done. Keeps exposure time to a minimum.

Anyhow, the problem in MS's court *at all*. All that's happening is MS is letting OEMs shoot themselves in the foot if they want to by not using a similar scheme as the one I've outlined. I'm not going to take "freedom, freedom" stuff seriously when it's in the same sentence as advocating MS to take away freedom from the OEMs.

@273 a root exploit is a bad enough problem and hardly needs to modify the kernel or bootloader in order to do just about anything. Seems like a corner case to me and a lot of effort to prevent it. It seems more plausible that the primary reason is anticompetitive, but of course it is difficult to judge motives, isn't it?

@smeezekitty agreed, optional usually turns into usual with no way to turn it off, and in this case Microsoft gets to blame the OEMs.

No, it's not an "edge case" it's a foundation. If you don't know your boot loader is secure you don't know your kernel is secure and you don't know that anything else is. It's a starting point for a secure system which, as I have mentioned already, is a pretty well-known security principal and nothing new.
I have no love at all for M$ and, in fact, wish they would go bankrupt and disappear but I see no problem with the idea of securing bootloaders.

The OEMs shouldn't be given freedom because if they do, they will just cost cut however they can at the expense of consumers.

Boot time exploits are not even a big problem in many business and server systems that have very long uptimes thus a running system exploit is the biggest danger.

@273 Ah, fair point. I suppose if you were sure of the bootloader and kernel, you could always reboot in a restricted mode (eg safe mode in windows) and be sure that nothing unauthorized was still active.

Secure Boot is not meant to stop attackers with physical access to the machine, there is in fact only one security feature that can help this with this scenario and that is whole-disk-encryption, and even then it prevents only casual attackers, the three letter agencies will still have no problem to press you to give them the password (they call that "enhanced interrogation").

Rootkits are not a corner case problem, they are real and a threat. Secure Boot is designed to prevent those attacks.

A compromised system is a compromised system, no matter how it was compromised. Dismissing a security feature because there are other ways to compromise a systems seems to me to be short sighted.

Sure. I'm more thinking "molly guard" type of security than anything else. The minor inconvenience is not meant to stop it entirely, but simply act as a "really really?" confirmation. When talking physical access, time is still a factor. It's reasonable to want to make sure Secure Boot can't get flipped off with 10 seconds of access, but not protect against 5 minutes.