Wikipedia:Reference desk/Archives/Computing/2018 March 21

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 21

UEFI

I wasn't aware of how bad the situation had gotten with UEFI, where some people apparently actually have to pay Microsoft tax and agree to their total control over Linux modules. [1] Our article isn't very clear nor up to date. What personal/laptop computers on the market now can or can't be turned into pure Linux boxes without kneeling to Microsoft's royal throne? What Linux distributions are not paying any fees? Wnt (talk) 12:02, 21 March 2018 (UTC)

It's not that bad. On x86 (32 and 64 bit), Microsoft mandates that the UEFI firmware support unsigned booting using the old BIOS way - which is perfectly sufficient for most of us. For UEFI boots on that architecture, Microsoft has signed shims for Fedora and Canonical and some others; as I understand it, the Canonical shim will chain boot anything (well, except Windows). There is an issue if you actively want Secure Boot - that's useful particularly for embedded devices, kiosks, high security devices like ATMs, and maybe some servers - where you actively don't want any old OS image to boot, even if someone gets physical access to the machine. To achieve that, a vendor needs to be able to add their own keys, so they can sign their own. There's also a mechanism for that. Note the three number points in this old post by Linux' secure-boot specialist Matthew Garrett. But yes, there is still a whiff of Microsoft having control over a platform that it doesn't actually own, even if it currently doesn't choose to assert that control nearly as hard as it could. -- Finlay McWalter··–·Talk

Things were that bad on Windows10 on ARM architectures. There Microsoft mandated the opposite of Garrett's 3 points - effectively you couldn't boot anything but Win10. That's because MS considered Win10_ARM to be an appliance, in the same way TVs, tablets, and phones running Android and iOS are. People are, unfortunately, willing to buy those with locked down secure boot loaders that will only chain to the specific vendor's OS image. But Win10_ARM seems to be a massive failure. Other than Android and iOS devices (and SBCs like Raspberry Pi), the only ARM consumer computers that I'm aware of are Chromebooks, which (as far as I can tell) all allow "developer mode" to boot regular (non Google) Linux. -- Finlay McWalter··–·Talk 14:25, 21 March 2018 (UTC)

Windows 10 on ARM is still very new. It may fail, but I don't think you're actually thinking of Windows 10 on ARM. Windows RT was basically Windows 8 on ARM which did fail and was never updated to Windows 10 which is what you seem to be thinking of. Windows 10 did have a mobile version for phones (not tablets) which was ARM based, and also failed, and this did require that secure boot couldn't be disabled but I'm not sure this is what you're thinking of either.

Also I don't believe Microsoft ever required that legacy BIOS support was provided. I'm pretty sure they only required that secure boot could be disabled. Most vendors did include legacy BIOS mode, as well as allowing secure boot to be disabled in UEFI mode. As I mentioned below, this is no longer a requirement on Windows 10 anyway. And it's likely legacy BIOS mode will be gone in 2020 or sometime after, for reasons that have nothing to do with Microsoft.

Secure boot issues aside, most OS developers seem to have accepted that BIOS is dead and have embraced UEFI. While the rise of SSDs and cloud storage has changed thing, it seems that whatever native sector size, 512 byte logical sectors are here to stay at least in the consumer world. (I'm not even sure if most computers support 4k native but in any case all consumer devices are Advanced Format with zero indication of moving to 4k native.) So it's likely the limits of MBR are going to be hit again, well and some people are still using HDs including ones larger than 2TiB for their boot drive. (Well you can already get SSDs bigger than 2 TiB, they're just very expensive.) Meaning that at least one of the limits of BIOS is going to be hit again. (I mean I'm sure it is possible to boot GPT from BIOS, but no one is doing that.)

Frankly all other issues aside (like for software developers, firmware writers), from a consumer POV UEFI boot without secure boot is a godsend for simple booting. Just being able to make a FAT32 partition and copy the boot files. And particularly for a FAT32 USB stick just copy the whole live OS rather than having to fiddle around with putting the boot sector in the right place with whatever tool, which then does boot on some other computer for whatever damn reason makes you wish they'd started this a long time ago. To be fair, the inability to easily partition most USB sticks does mean you're stuck having the whole stick as FAT32 (well or FAT16) which can create issues but for me at least it's a minor one in comparison. In other words, don't conflate secure boot with UEFI boot.

Nil Einne (talk) 15:50, 21 March 2018 (UTC)

(EC) ARM versions of Windows required secure boot and that it couldn't be disable but basically completely failed. (In any case, mistakes means people have found simple ways to disable secure boot with those PCs [2] [3].)

On x86, with Windows 8 for certification Microsoft requires that Secure Boot is enabled but default but that it can be disabled by the end user [4]. With Windows 10, Microsoft allows manufacturers to choose whether to let users disable secure boot [5] although still recommend it is disableble [6]. Of course vendors were free to forgo Windows certification and prevent secure boot from being disable even with Windows 8. But I'm not aware many vendors have chosen prevent secure boot from being disabled even with Windows 10 certification allowing it.

Considering increasing concern over security it's possible this will happen, especially as some would suggest all possible avenues of attack should be locked down as far as possible, and vendors are much more concerned what their corporate clients want rather than some random person who wants to install another OS. (Although vendors also don't want tons of support requests when people are trying to do things like use some sort of old recovery software or run memtest or whatever so also don't tend to do stuff unless they feel it's necessary.) But most flaws relate to other attack avenues for bypassing secure boot rather than the fact that it can be user disabled e.g. [7] [8] or the previous flaws of Microsoft's leaked credentials. (In fact, experience on Android and iOS perhaps suggests that a risk of preventing the user disable the feature is that you get a lot more people looking for flaws to exploit.)

Incidentally I'm fairly sure Microsoft makes zero money from signed bootloaders. It all goes to Verisign. Microsoft are probably losing money given their legal teams, security teams, software development teams are often involved. So frankly the 'tax' thing is fairly silly, if there is any concern it would be with the requirements, contract etc. [9]

In any case, most Linux distros or for that matter other OSes can likely use the Linux Foundation preloader [10] [11] or the Fedora shim [12] or some other similar alternative so it's more of a matter with whether people are comfortable using this given the requirements etc that it had to meet rather than a cost issue. (Remember that you will need an EFI boot loader unless you are in legacy/BIOS mode regardless of whether secure boot is enabled. Legacy mode is likely to be killed off at some stage perhaps in 2020 probably due to Intel [13] [14].)

Bear in mind these are areas you have to take great care with any source since a lot of wacky conspiracy theories easily spread [15].

Nil Einne (talk) 15:21, 21 March 2018 (UTC)

Actually it looks like I'm wrong. (I mentioned the conspiracy theories bit, the other thing is that you'll find a lot of alarmist stuff when something is suggested, and a lot less talking about future changes which are less alarmist.) Per this Microsoft document, Windows 10 certification still requires that secure boot can be disabled so I guess Microsoft dropped the proposal to make it optional [16].

Also I should make it clear I'm not denying some people may be concerned about having to agree to Microsoft's conditions etc including the control this gives them. In fact some of my refs do mention the requirements and concerns. My point was solely that it's silly to make out, as some other sources and the first post made out this is some sort of direct money making exercise for Microsoft, it's clearly not. (This is also silly because Microsoft is surely much more interested in the control than in some pittance.)

As a final point, I'd note that per that document, Microsoft only requires secure boot is enabled by default and that the Microsoft root is trusted. They don't prevent other roots from being trusted. In other words, the only reason why Microsoft comes into the signing process is because it's far easier that way. Theoretically OS developers could get vendors to trust their own roots and bypass Microsoft. And while Microsoft has done some dodgy things in past, it's fairly unlikely in this day and age they will have any desire to secretly convince them not to. The reason why it ain't happening is because vendors just aren't going to bother nor are even the big distros interested in making the effort. Microsoft's process may not be to everyone's cup of tea, but it's far easier than the alternative.

Nil Einne (talk) 16:42, 21 March 2018 (UTC)

Notice the linked article is from 2012, so this has been going on for quite a while now. However, I don't remember having any problems with UEFI. I've been fully successful in dual-booting Fedora 26 Linux and Windows 10 on a used HP Z420 workstation. Maybe Fedora is one of the distributions who decided to play nice and pay for this "Microsoft tax"? JIP | Talk 08:59, 23 March 2018 (UTC)

The Fedora project made the one-time $99 payment to Microsoft. Technically, it went to Verisign, not Microsoft, but we all know it is an evil Microsoft tax. It was a brutal tax that nearly crippled the entire Linux world. Some claim that it is slowly recovering, but that remains debatable. 209.149.113.5 (talk) 11:32, 23 March 2018 (UTC)

Does Facebook Zero have an API?

Does 0.facebook.com have a public API? -- 129.45.120.177 (talk) 18:34, 21 March 2018 (UTC)