Veteran FreeBSD developer Marshall Kirk McKusick, who brought this to the notice of iTWire, said "It turns out there's a new wrinkle in the original secure boot incremental plan - Microsoft's policy on signing 3rd party EFI code has changed."
The relevant portion of the post at MSDN runs thus: "5. All code modules must be authenticated before execution. If this is not the case, submissions won't be signed, and, if already signed, are subject to revocation."
FreeBSD has begun the process of implementing secure boot support for the distribution and it was in this context that McKusick made mention of this change.
All machines that come with this operating system have secure boot turned on by default; thus any other operating system which has to be booted on such a machine also needs to support secure boot.
McKusick said this change basically closed the original loophole that allowed a signed bootloader to load an unsigned next stage (i.e., kernel).
"In the short term a signed version of the shim loader exists today and will load an unsigned EFI application," he said. "I believe it should allow us to boot an unsigned FreeBSD in a secure boot environment, but it sounds like it may be revoked. This path will be useful for us to gain experience, but does not seem like it will be deployable in production on
an ongoing basis."
He said that in the longer term FreeBSD would need to execute on the full plan to guarantee it could work with secure boot.
"We'll need to be able to sign kernels and modules, and verify those from the loader. But, deploying the intermediate solution (used also by Canonical) will not be possible (as it might be revoked in the field by Microsoft)."
Fedora, Red Hat's community GNU/Linux project, was one of the first distributions to include support for secure boot with openSUSE, the community distribution supported by SUSE Linux, and Ubuntu, the most widely used distribution, not far behind.
Asked for comment, Fedora community spokesman Adam Williamson said: "I don't believe it (the change in Microsoft's policy) has any significant impact on us.
"As I understand it, this is basically about being stricter on stuff like requiring signed kernel modules and preventing ksplice execution - preventing things in the booted environment from subverting Secure Boot."
Ksplice, developed by a private company of the same name and acquired by Oracle in 2011, is a mechanism for patching a running kernel.
Williamson added: "Fedora has already been careful to prevent the booted system subverting secure boot, because we actually want secure boot to *mean* something on Fedora, not just be a box-checking exercise. When you boot Fedora with secure boot enabled, you get a properly secured boot chain. If you don't want that, you can easily boot with secure boot disabled."
Stephan Kulow, a spokesman for the openSUSE project, said Microsoft's changes had no direct influence on openSUSE.
"openSUSE grub only loads signed kernels. The kernel itself loads unsigned modules as we don't want to take away that freedom from the user," he said in response to a query.
"To comply with the stricter interpretation of the secure boot policies, it's on our TODO list for the next release to offer a prompt so the user ACKs that openSUSE kernels will offer that freedom.
"Only loading signed modules would make the offering of graphics drivers even harder for us and we are convinced people would deactivate secure boot completely if they had to choose between graphics drivers and secure boot. We think educating the user about the reasoning is the best option."
Rick Spencer, the vice-president of Ubuntu Engineering, said: "Our interpretation has historically been that our UEFI secure boot implementation is required to sign and verify all code that runs before ExitBootServices (which we do), since that is running in the privileged pre-boot environment, but not to verify code that runs after that point.
"The Ubuntu kernel is signed and verified in order that we can hand off to it before calling ExitBootServices and thus allow it to do some of its own set-up code in (the) boot services context, but at present our boot loader is configured to also allow handing off to unsigned kernels after calling ExitBootServices.
"This is to avoid putting unreasonable obstacles in the path of users who need to test experimental kernels or build their own, which we feel to be an important ability to preserve for both practical and ethical reasons."
Spencer added that that said, the company was aware of Microsoft's announced changes.
"To address these without impairing users' ability to modify their operating systems, we have so far deployed a version of shim including basic support for setting a Machine Owner Key (MOK), allowing users to register their own signing key without having to type long strings of hexadecimal into complex and inconsistent UEFI BIOS setup screens.
"For Ubuntu 14.04 LTS, (which is due in April) we intend to integrate mokutil into dkms and the GRUB installation scripts to make it straightforward for users to manage this. Once this is working, we will be able to disable support for unsigned kernels with a clear conscience."