Both papers, one from the Linux Foundation, and the second a joint effort from Red Hat, Canonical and Parallels, were released on October 28.
But, as the Linux Foundation paper (PDF) points out, GNU/Linux and other open operating systems can only take advantage of secure boot if it is implemented properly in the hardware. Control rests with the hardware vendor who, in turn, will be under pressure from Microsoft.
The Windows 8 secure boot process was made public in September when a developer preview of the operating system was released.
Windows 8 uses specifications from the Unified Extensible Firmware Interface -that defines a software interface between an operating system and platform firmware - namely the secure boot protocol, to ensure exclusive booting rights on hardware.
The fact that this process could, theoretically, be used to lock out other operating systems was initially noticed and commented on by Linux kernel developer Matthew Garrett; Microsoft reacted to this with its own comments but did not alleviate any of the concerns he had raised.
There was concern voiced, among others, by Australian GNU/Linux users, some of whom complained to the Australian Consumer and Competition Commission; their complaints earned them form letters in response, letters that excited some tech outlets which saw in them reason for hope when there was none.
That the two papers referred to earlier have been released so soon is an indication that Microsoft's plans are occasioning considerable unease in free software and open source software circles.
The Linux Foundation paper details how the UEFI secure boot process can work with open platforms; GNU/Linux vendors Canonical and Red Hat have set forth the impact the UEFI secure boot will have on GNU/Linux.
A secure boot is ensured by communication between the system firmware and the operating system executable; the system firmware can contain one or more signed keys and any executable that is not signed by these keys will not boot on the system in question. Another set of keys allows for communication between the operating system and the firmware.
The Foundation paper contains a series of recommendations to hardware vendors on how a secure boot process can be incorporated without prejudicing the rights of users of other operating systems; it also details the reasoning behind these recommendations.
Written by James Bottomley, the chief technical officer of server virtualisation at Parallels, and Jonathan Corbet, a Linux kernel developer, recommends that every platform that provides a secure boot using the UEFI specifications should be sold in setup mode.
This would give the buyer control over which platform key is installed and would also make it possible for the owner to return a system to setup mode later on if the need arises; say, if one decides to install another operating system.
When the initial bootstrap of an operating system occurs, the fact that the platform is in setup mode would be detected. The operating system would then install its own key-exchange key and install a platform key to enable secure boot.
In order to cater to users who want dual-boot systems, the Foundation paper recommends that a mechanism, based in the firmware, should be established to allow a platform owner to add new key-exchange keys to a system running in secure mode.
The paper also recommends that there be a firmware-based mechanism to make the booting of removable media easy. In conclusion it says that an authority should be established to issue key-exchange keys for third-party hardware and software vendors. Such an authority should be neutral when it comes to both operating systems and vendors.
The second paper, (PDF) written by Bottomley, Jeremy Kerr, technical architect at Canonical, and Garrett, who is a senior software engineer at Red Hat, once again contains recommendations that hardware vendors should adopt if they wish to cater to all operating systems.
The authors recognise the real reason why Microsoft has suddenly resorted to a secure boot. "The UEFI specification for secure boot does not define who controls the boot restrictions on UEFI platforms, leaving the platform implementer in control of the exact security model," they write.
"Unfortunately, Microsoft's recommended implementation of secure boot removes control of the system from the hardware owner, and may prevent open source operating systems from functioning. The Windows 8 requirement for secure boot will pressure OEMs to implement secure boot in this fashion."
The authors point out some of the reasons why proprietary software vendors may favour a secure boot. For example, a specific piece of hardware can be tied to software and any future version of system software may require an upgrading of this specific piece of hardware.
Or if the secure boot process is used to verify all software, including the binaries of applications, then the owner of the key can ensure recurring income by specifying that all applications be installed only from a central location like an App Store.
Given that most of the malware that attacks Windows only does so after installation, Microsoft's sudden interest in a secure boot process has to be viewed with some suspicion.
That Linux vendors and the Foundation have reacted at this early stage indicates that they will be using whatever clout they have with hardware vendors to lobby for an open implementation of secure boot so that GNU/Linux and other open operating systems are not disadvantaged.
But then, given that Microsoft has fallen so far behind other big technology companies like Google and Apple, and also the fact that most of Microsoft's earnings still come from Windows and Office, it is highly unlikely that the good people at Redmond will be keen to look kindly on the Linux Foundation's recommendations.