Recently, we discovered that any user who buys a Windows 8 machine and wants to dual-boot with another operating system — any Linux flavour; any BSD distribution; even previous Windows versions such as Vista, Windows 7 and Windows XP — will be unable to do it if secure boot is enabled.

Now, clearly, the obvious solution to this situation is to disable the feature, and that is the solution that Microsoft is standing behind.

“Microsoft supports OEMs having the flexibility to decide who manages security certificates and how to allow customers to import and manage those certificates, and manage secure boot,” wrote Microsoft senior program manager Tony Mangefeste.

The tin-foil hat crowd will point out that the flexibility to do something is also the flexibility to do nothing at all — and for once they appear to be right, as Red Hat developer Matthew Garrett points out.

“We’ve already been informed by hardware vendors that some hardware will not have this option,” wrote Garrett.

As an operating system that holds over a 90 per cent share of the market, vendors are naturally going to follow Microsoft’s lead and concentrate on Windows compatibility and having the precious Windows logo certification; some vendors will concentrate on Windows alone. For proof of this mindset, look no further than wireless support on Linux — all these years of hard work and occasionally one can still be tripped up on a bad driver.

Not to mention the myriad of problems with various pieces of hardware throughout the years: graphics cards, RAID controllers, USB devices — they’ve all been an issue at one time or another, mostly because vendors do not wish to share details to make native Linux drivers available.

Two years ago, I was bitten by insufficient hardware research as I attempted to conduct an Oracle review.

“Since I am not a sysadmin everyday, I forgot about the wacky world of motherboard bus controllers and the varying degree of Linux support. Suffice to say that for the foreseeable future, I will not make this mistake again,” I wrote at the time.

“Installing Linux is not an activity I recommend with the Asus RS700-E6. Despite AHCI, RAID or legacy IDE modes being available, none were sufficient to install the OS and have it boot correctly without a significant amount of GRUB manipulation.”

Of course, the aforementioned Asus server came installed with Windows Server and worked flawlessly with it — I had naively assumed that it was insignificant which server hardware I chose.

The secure boot move now means that everyone who wants to pack an alternate operating system on their machine is going to have to watch their purchases extremely carefully as I should have when conducting that review.

The horrible irony of this situation is that Microsoft is following the UEFI specification, as well as having a genuine case for wanting to protect users from malware during boot — but this can only be done when vendors keep the signing keys out of the hands of users and malware creators.

Unfortunately for Linux distributions, the GPLv3 explicitly states that signing keys must be provided to users, thus any keys used to sign a distribution must also be available to users and hence malware creators as well.

If Red Hat, Canonical or any other Linux distribution could convince vendors to ship systems with their keys, then an attack vector is immediately available for malware that otherwise would not have been.

And do not think for one minute that this is only an open-source problem.

For enterprise users, the issue still remains if they have not purchased Windows 8 licences. They will need to make sure that the hardware supports disabling of the secure boot feature in order to install Windows 7, Vista or XP.

We have all seen how clingy enterprise desktops are to Windows XP, so systems administrators will need to be mindful of secure boot for much of the foreseeable future.

Hopefully vendors will realise the issues with secure boot and make sure that the ability to disable it is worth having or are at least merciful to customers at the return counter.