Ask Slashdot: Establishing Procurement Policies Regarding Secure Boot?

New submitter Firx writes: My university department has a tradition of selling its used computers and/or repurposing them with Linux for graduate students and science computer labs. With Windows no longer requiring one be able to disable secure boot, my department is writing up a procurement policy to ensure future machines we buy will still have this feature. Part of the draft motion reads: "Be it resolved that computers running or intending to run Microsoft Windows purchased by the department which boot using the Unified Extensible Firmware Interface (UEFI) have the ability to disable the Secure Boot features for both local hard drive and network booting." Is there something further we should be including here and what is the best way to explain the need for this policy to colleagues less technically literate?

Comments

Add a test

[gweihir]

Require it, for example, to be installable with Linux with the "current version of the stable Debian installer" at the time of purchase. For an individual contract, that version needs to be specified, of course. This way you have at least somebody to blame if it later turns out this does not work.

Re:Add a test

[mysidia]

Require it, for example, to be installable with Linux with the "current version of the stable Debian installer" at the time of purchase.

(1) Test1: Netboot to CloneZilla Live Image.
(2) Test2: Boot system from IT Rescue USB Stick
(3) Test3: Debian installer from CD and Boot to OS from hard drive following installation

All 3 tests must pass for each system.

Re:Add a test

[mattventura]

You don't have to do it for every single PC purchase, just once for each model.

Re:Add a test

[sjames]

What if IT doesn't want to bother with the purchase at all? What if all major couuriers including USPS up and quit? What if a solar flare wipes out civilization before it arrives?

I would imagine there would be some sort of requirement listed in the P.O.

Expalnation

[QuietLagoon]

what is the best way to explain the need for this policy to colleagues less technically literate?

We bought the computers, we should be able to use them as we see fit.

Re:Expalnation

[fahrbot-bot]

what is the best way to explain the need for this policy to colleagues less technically literate?

We bought the computers, we should be able to use them as we see fit.

Would you want a car that only accepts fuel from one gas station company?

Re:Origin

[Anonymous Coward]

Since all the hardware is inevitably from China, it makes little difference.

Linux can UEFI Boot

[Zombie Ryushu]

Linux can UEFI Boot with and without Secure Boot. With Secure Boot you have to be able to install keys or use a Grub Shim, but I have seen both Toshiba and HP Laptops boot Mageia and RedHat in UEFI and CSM modes.

Re:Linux can UEFI Boot

[vel-ex-tech]

Oh good grief. Fine.

My mobo allows me to load my own keys. I'm assuming it's not the only UEFI implementation on the face of the planet that allows one to load one's own keys. I'd be secure booting my systemd-free Gentoo install if not for sheer laziness.

Re:Linux can UEFI Boot

[wolrahnaes]

Then, how do I recompile a custom kernel and with UEFI Boot and Secure Boot run it?

Depends on how your distro of choice has implemented Secure Boot.

All of the distros with official support are using a shim derived from Red Hat's. That shim is a very simple bootloader which maintains compliance with Secure Boot by only chaining on to verified binaries, but it allows the use of an additional public key which has been compiled in to the binary. Anyone who finds it worth the $99 can have their build signed by Microsoft and will then be able to boot anything signed with the associated private key on top of anything signed with the Microsoft keys the system has built in. It also provides a method to pass the public key down the chain so the next stage bootloader, kernel, and beyond can verify with it as well.

Fedora and Ubuntu stop here. Fedora signs GRUB2 with their key which then verifies the kernel, which then verifies the modules. ( http://mjg59.dreamwidth.org/12... ) Ubuntu jumped on a loophole in the wording of the Secure Boot spec to just use their key to sign a bootloader which will then happily launch an unsigned kernel. ( https://lists.ubuntu.com/archi... )

Suse took things a step further and expanded the shim to support a local key list in the UEFI configuration area. ( https://www.suse.com/communiti... ). Now even a system that lacks the ability to add keys to the firmware's verification process can run a fully signed boot process with custom keys.

Finally one of the main original developers on the shim who has since left Red Hat took Suse's key management code, mixed it with his own continued tinkering, and added a user interface that comes up if you attempt to boot a signed binary that doesn't match an approved key, allowing the user to browse for a key on any accessible storage and add it to the system. ( http://mjg59.dreamwidth.org/20... )

---

So the answer depends on your distro. If you're running Ubuntu, you just compile your new kernel and go have fun because Ubuntu's not yet verifying the kernel (this is apparently becoming optional in 16.04). If you're running Suse, you use whatever tool they offer to add a key to their shim's list. If you're running Fedora, you replace their shim with one of the other variants and either add a key of your own or just go Ubuntu-style and drop it at the kernel.

Of course this is all assuming your system doesn't allow you to change the keys, which I know is a valid theoretical possibility but I still haven't encountered in the real world.

Re:Linux can UEFI Boot

[psyclone]

Thanks for the detail!

Arch Linux uses EFI BOOT STUB which allows you to secure boot with your own keys if you like.

Re:Linux can UEFI Boot

[Anonymous Coward]

You, maybe. With your current mainboard. Everyone else generally, not so much. So for general distribution other OS distributors are still dependent on a direct competitor to sign their bootcode for them.

Yes, it does indeed mean OS distributors need signatures from a direct competitor. That's fair and reasonable, right? Right?

On top of that, redmond is already slowly turning on the screws. So next upgrade, who knows? Following this and also their earlier business practices, it is not merely conceivable, it is probable, that they'll soon require most hardware to be sold locked down (as they already did with "RT" tablets!), and then you can no longer load your own keys, except maybe if you pay for enterprise support from an enterprise dealer for enterprise rates and so if you want to have your own peecee with loadable keys... you have to buy maybe at least a thousand. They have pulled this trick before, tricks like it multiple times, and there is no reason in the world why they would not again.

So yeah. Good grief. Very fine.

Not all computers have UEFI

[Anonymous Coward]

You are both over-specifying the mechanism, and scope.

Not all computers you can buy to run Windows have UEFI, and some otherwise useful devices can't disable it.

2 examples that would be excluded from purchase by how you have phrased this :

- Macs (do not have UEFI, but an Apple fork of EFI)
- iPads (locked boot loader)
- Many Windows 10 tablets/hybrids/ultrabooks e.g. Surface (locked boot loader)
- Windows Phone (locked boot loader)
- Sony Playstation (sometimes used as GPU clusters, but have a locked boot loader )

Now if you want to ban those other device types , thats really up to you. It depends on do you consider a tablet to be a computer or a phone to be a computer, but heck. Increasingly , the number of computers that function as you describe are going to go down, and more and more locked down devices like tablets and hybrids will become the norm in the market.

Why not frame it in terms of why :

"The department believes that it is essential to generate long term utility from computers it buys, and that they shouldn't simply be disposable. We believe that long term use requires flexibility in the operating system used on a computer. We believe that long term use can be achieved in multiple ways - such as reselling used devices to other entities that have need for them, re-purposing computers for graduate students and laboratories, or converting computers for use in instrumentation. This means that wherever possible, computers should be purchased ensuring they have the capability to be unlocked from only running Windows, and running other operating systems such as Linux. This ensures maximum flexibility for our department in generating value from the money we invest in our IT hardware. Exceptions to this need to present a business case and be approved by XXXX"

The committee approving the exceptions is the mechanism to handle your other options.

Re:Not all computers have UEFI

[c]

It's also worth pointing out that there's a lot of devices which allow the bootloader to be unlocked, but then are no longer covered by the manufacturer's warranty. These should be avoided.

Why mention Windows?

[bws111]

Other than pure FUD, why mention Windows or Microsoft at all? We have hundreds of servers running Linux that have Secure Boot enabled, and our requirements for the next gen of servers is that the Secure Boot can not be disabled. So don't pretend it is just a 'Windows' thing.

Dragging MS into it is really childish. A manufacturer that gets a Windows 10 cert has the choice of allowing Secure Boot to be disabled or not. Are you trying to claim that a manufacturer who DOESN'T get an MS certification is somehow prevented from that option?

Re:Why mention Windows?

[bws111]

Who signed it? We did. And anyone who has the passwords required to access the UEFI does not have physical access to the servers without accompanied.

Re:Why mention Windows?

[Trogre]

Simple. Microsoft Corporation holds the keys to your Secure Boot chain of trust. Or did you manage to get someone else to sign your bootloader?

Re:Why mention Windows?

[ilsaloving]

Are you trying to claim that a manufacturer who DOESN'T get an MS certification is somehow prevented from that option?

I think you misread the question. The question was about requirements for purchasing products from vendors, not telling vendors what they are and arn't allowed to do. (That's Microsoft's job)

There's nothing childish about mentioning Microsoft explicitly. They were the ones that championed Secure Boot in the first place, forcing OEMs to implement it for certification. Most major linux vendors have the resources to get their boot keys into the database, but smaller distros probably wouldn't.

Even then, the database is then stored locally in the UEFI, so if there's a Linux distro that's late to the party, they're still screwed with the current generation of hardware unless a bios update is released.

Additionally, Windows 8 certification mandated that it must be possible to disable Secure Boot (after significant outcry about possible lock-in). But for Windows 10 certification that requirement has been quietly dropped again, once again raising that concern about lock-in.

The submitter has stated that their guidelines will require any new hardware to have the ability to disable SecureBoot, certification requirement or not.

The question is, how do you explain that to people who may not understand the technical nuances.

The easiest way I can think of, is to make sure the hardware provides the ability to install Windows 7 (Just because Windows 10 licensing permits downgrade rights, it doesn't follow the hardware will let you), which doesn't support SecureBoot. If you can install Windows 7, you can anything else you want.

Re:Why mention Windows?

[Anonymous Coward]

False. The reason why MS has the keys is that to have your product certified to run on Windows, this is a must. Same with TPM + TCG 2.0. It was only due to good negotiators on RedHat's part that MS allows their OS to boot, -period- on Secure UEFI computers.

Re:Tablets?

[Anonymous Coward]

You are able to disable Secure boot on the x86 Surface tablets, I have it disabled on my first gen Surface Pro. Even the newest ones apparently support disabling it according to Microsoft's documentation on them.

No such luck for the ARM Surface tablets.

Put it in the budget

[davidwr]

For computers that can be re-purposed or re-sold, the actual residual value after 3 years (or whatever your "time to fully depreciated" is) significantly greater than zero.

For "locked down" computers, the actual residual value becomes a cost - the cost of having it hauled off as e-waste.

In cases where computers must be locked-down (e.g. due to a grant requirement), the "true cost" should be the buy-in cost + the ongoing maintenance cost - the residual cost (or ... + the disposal cost).

By explicitly calling this out in your requisition process, it will make people think twice before applying for grants that require locked-down computers.

Fixed that for you

[Aryeh Goretsky]

Hello,

I would suggest the following amendment to your draft text:

Be it resolved that computers running or intending to run Microsoft Windows purchased by the department which boot using the Unified Extensible Firmware Interface (UEFI) have the ability to disable the Secure Boot feature." REMOVING: s for both local hard drive and network booting.

If you want to put in verbiage saying Secure Boot should be disabled, the language should reflect this in its entirety, not just for what types of devices the computer boots from. Example: A manufacturer who disabled booting from SSDs, USB flash drives or optical media would still be in spec with your requirements, since you only specified hard disk drives and PXE booting in your text.

Also, keep in mind your requirement is not going to work with Windows 10 Mobile devices (phones, phablets and the like) as UEFI with Secure Boot enabled is part of the requirements for devices running that edition of Windows 10.

Regards,

Aryeh Goretsky