The specifications in the company's Windows Hardware Certification Requirements make this clear, according to tech blogger Glynn Moody.
The issue of secure boot on Windows 8 was raised in September when Linux developer Matthew Garrett pointed out that this feature, implemented as per the Unified Extensible Firmware Interface guidelines, could be used to ensure that only Microsoft operating systems were loadable on a given device.
The system firmware can contain one or more signed keys and any executable that is not signed by these keys cannot boot on said system. Another set of keys - called Pkek - allows for communication between the operating system and the firmware.
An operating system with matching Pkek keys can add more keys to a whitelist - or a blacklist. In the latter case, any executable which has a key on the blacklist will not boot.
The Linux Foundation later provided a list of ways in which this could be bypassed, provided hardware vendors cooperated.
The Windows Hardware Certification Requirements (PDF) say, on Page 116:
20. MANDATORY: On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
c) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.
On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable (sic).
The Software Freedom Law Centre's Aaron Williamson said in a blog post that there could be many reasons for the differing policies between the requirements for ARM and non-ARM devices.
For one, the PC world is dominated by Intel, which is a founding member of the UEFI. Hence, in the case of Intel-based devices, Microsoft's requirements are close to those required by this body.
Secondly, ARM devices could be locked down without any fear of customer backlash as there was no support for older versions of Windows; on the PC platform, this was not the case. Customers who did not like Windows 8 might like to load Windows 7 or XP and would be angered if they could not.
And finally, the SFLC pointed out, there was no chance of anti-trust concerns being raised with regard to mobile devices as Microsoft had a very small share of the market. The reverse was the case with the PC and Windows.
"Before this week, this policy might have concerned only Windows Phone customers," Williamson wrote. "But just yesterday (January 11), Qualcomm announced plans to produce Windows 8 tablets and ultrabook-style laptops built around its ARM-based Snapdragon processors.
"Unless Microsoft changes its policy, these may be the first PCs ever produced that can never run anything but Windows, no matter how Qualcomm feels about limiting its customers' choices."