As far as I'm concerned as long as it's possible to re-enable the 3rd Party CA (or disable Secure Boot altogether) it's not tragic considering this only applies to a specific kind of machines ("Secured Core PCs") and not to mainstream ones
As far as I'm concerned as long as it's possible to re-enable the 3rd Party CA (or disable Secure Boot altogether) it's not tragic considering this only applies to a specific kind of machines ("Secured Core PCs") and not to mainstream ones
It is trivially easy to boot from a USB pendrive; most computers will do it by default if there's no preinstalled OS, many devices have a hotkey you can press/hold which redirects towards booting from USB, and even Windows itself will outright let you do it from the Settings app. You don't even have to interact with the system firmware setup program.
On the other hand, disabling secure boot (or taking ownership of it) is designed to be as difficult as possible, intentionally. Many vendors will actually have a Scary Boot Prompt or the like which makes you double-acknowledge when you change Secure Boot settings, and even reminds you (on every boot) that you have Secure Boot disabled.
It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't. This puts a glass ceiling on non-MS operating systems regarding how easy their setup flow can be.
Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
>Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
I think it more _accurate_ to have said "of course these systems are going to be configured to boot nothing but Windows out of the box", which is ... drum roll please.. anti-competitive. Facially, and blatantly anti-competitive.
We really must not conflate "predictable behaviour" or "established behaviour" with "acceptable behaviour" in any part of life including corporate crime.
If your instructions read: "turn off secure boot", MS has already won. Some users will, most won't, and many company IT departments would not allow you to on principle (because it's company hardware and they want it secured because it is their problem if it isn't).
That's the thing, you don't have to disable that. You just have to re-enable that CA if you have a model that has Device Guard enabled by default.
> It's an extra hurdle.
Hurdle that doesn't matter at all. If you have the skillset to install an OS, changing a setting in UEFI is nothing.
This is an extremely weird argument. So called Live CDs come from an era where CD drives were ubiquitous and even back then installing an OS (provided you did not want to install two OSes at the same time) was as simple as installing any other piece of software. If anything, with all these secure boot shenanigans it requires more skill to install an OS than when a smartphone was not even a thing. This argument advocates for walled-garden IT. This argument used in support of restrictions under the hood arguments for IT stuff to be hard in principle.
Also please keep in mind that it's not Secure Boot you have to disable, it's a CA you have to re-enable on machines that came with Device Guard pre-enabled.
You keep arguing all over the place that this is an insignificant obstacle, but do not address the very core of the debate: whether only MS keys being installed by default is for security purposes in the first place and whether it does actually increase security. We are not arguing how many hoops to install Linux (or whatever) is too much. we are arguing whether certain OSes should be easier to install at all.
In that case though, it's not "only MS keys" really, it's not enabling one CA. In the end if there's a strong need, Canonical, Red Hat or the likes could start building their own CA and negotiate it to be included, would be very fair and probably wouldn't be affected by this toggle. But they do not seem interested however in the much easier MS UEFI CA-signed Secure Boot, Ubuntu does it fine, but Fedora can't sign DKMS modules and the rest are even worse.
So the thing is, the problem of "trust" is very complex and putting in the work is very expensive. Microsoft has chosen to do this to improve their customers' security, they offer others the opportunity to participate and few are actually willing. That's not their fault really.
In the end they'd get slapped so hard by antitrust if they ever truly removed that toggle and the option to run other software. (Unlike Apple or other mobile vendors, who can do whatever they wish, with no such uproar over what is way worse than the toggle discussed here.)
That assertion is a bit too absolute; I am comfortable installing an OS using the USB installer because I have done it many times. I haven't had to change UEFI settings yet and I'm worried that doing something wrong will lock me out (in case of a botched OS install, I can just start over).
If we take the model the initial blogpost was about it's nicely documented: https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...
I run Linux on a used ThinkPad I got on eBay and I have no idea what this sentence means.
If you read what Secured Core or even Device Guard consists of, Linux actually does detract from it. I use Linux daily on all my machines, I have no sympathy towards Windows at all, but Linux has certainly fallen behind in some aspects - boot integrity and boot anti-tampering is one of those aspects. And that's not all Secured Core provides in the end.
Secondly, no, they aren't all proprietary. If we start from the bottom then Secure Boot is neither proprietary or NDA'd. There are even open-source implementations of Secure Boot. We simply have a significant amount of feet-dragging and misconceptions out there, pointlessly making using just SB alone difficult and not the default, you can see a bunch of it in this thread as well.
I won't even get into measured boot to auto-unlock FDE/LUKS or god forbid LIM, those aren't difficult because of some supposedly NDA'd specifications. Damn, enabling IOMMU isn't that difficult either. Nobody else should be blamed for the poor state of those.
Lastly, some standard being initially released under NDA or being proprietary (which ones do you actually have in mind?) is a terrible justification to not improve things. Or find alternatives just as good.
I think them being NDA / proprietary is a reason we can't improve things, not a justification for it.
It's either a neutral organization signing certs which you then have to accept by default, or you get fined. Those are the only acceptable scenarios.
Apply some basic logic to the conversation.