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?
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.
Since all the hardware is inevitably from China, it makes little difference.
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.
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.
The only reason MS has the keys is because everyone else is too lazy to do it right. We sign our own images, and our key is the only one that will boot.
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.
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.