Slashdot Mirror
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?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
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.
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.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.