decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Monday, July 02 2012 @ 01:37 PM EDT

The Free Software Foundation has released a whitepaper on Microsoft's Secure Boot. It analyzes both Fedora's and Ubuntu's current solutions and offers its own.

In particular, it debunks Ubuntu's expressed worry about the GPLv3 license on Grub, a worry that it says is legally unfounded. Apparently Ubuntu never contacted FSF to inquire, which his unfortunate, despite FSF being the copyright holder of Grub and the "primary interpreter of the license in question", as Sullivan puts it:

Our main concern with the Ubuntu plan is that because they are afraid of falling out of compliance with GPLv3, they plan to drop GRUB 2 on Secure Boot systems, in favor of another bootloader with a different license that lacks GPLv3's protections for user freedom. Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.

This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.

Furthermore, addressing the threat of Restricted Boot by weakening the license of the bootloader is backwards. With a weaker license, companies will now have a form of advance permission to obstruct the user's ability to run modified software. Rather than work to make sure this situation does not happen -- for example by enforcing the proper Secure Boot implementation they say they "strongly support in [their] own firmware guidelines" -- Ubuntu has chosen a path which explicitly allows Restricted Boot.

No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue.

With regard to Fedora's approach, Sullivan writes that while it's a thoughful effort that results in GPL compatibility, trusting Microsoft is not an option: "Encouraging free software distributors and users to trust Microsoft or any other proprietary software company as a precondition to exercising their freedoms is simply not an acceptable solution."

FSF has a number of suggestions going forward, including helping users to learn how to do what they can do to protect themselves, and it is also working with companies like Lemote, Freedom Included, ZaReason, ThinkPenguin, Los Alamos Computers, Garlach44, and InaTux to make computers available that are preinstalled with fully free GNU/Linux distributions.

The summary:

The best solution currently available for operating system distributions includes:
1) fully supporting user-generated keys, including providing tools and full documentation for booting and installing both modified and official versions of the distribution using this method;

2) using a GPLv3-covered bootloader to help protect users against the dangers of Restricted Boot;

3) avoiding requiring or encouraging users to trust Microsoft or any company which makes proprietary software; and

4) joining the FSF and the broader free software movement in pressuring computer distributors to facilitate easy and independent installation of free software operating systems on any computer.

I thought it was an important enough worry for all of us in the FOSS community that it should be reproduced here in full, so you have it when making your own decisions on what you personally wish to do. I am, of course, disgusted that once again Microsoft is making it harder to use FOSS, but we've also seen over time that the community is resourceful. If Groklaw can be helpful in making documentation clearer, for example, I certainly will be happy to help out. No doubt you feel the same.

***********************

Free Software Foundation recommendations for free operating system distributions considering Secure Boot
~ by John Sullivan

Introduction

This paper is also available as a PDF.

We have been working hard the last several months to stop Restricted Boot, a major threat to user freedom, free software ideals, and free software adoption. Under the guise of security, a computer afflicted with Restricted Boot refuses to boot any operating systems other than the ones the computer distributor has approved in advance. Restricted Boot takes control of the computer away from the user and puts it in the hands of someone else.

To respect user freedom and truly protect user security, computer makers must either provide users a way of disabling such boot restrictions, or provide a sure-fire way that allows the computer user to install a free software operating system of her choice.

Distributors of restricted systems usually appeal to security concerns. They claim that if unapproved software can be used on the machines they sell, malware will run amok. By only allowing software they approve to run, they can protect us.

This claim ignores the fact that we need protection from them. We don't want a machine that only runs software approved by them -- our computers should always run only software approved by us. We may choose to trust someone else to help us make those approval decisions, but we should never be locked into that relationship by force of technological restriction or law. Software that enforces such restrictions is malware. Companies like Microsoft that push these restrictions also have a terrible track record when it comes to security, which makes their platitudes about restricting us for our own good both hollow and deceitful.

The GNU General Public License (GPLv3) shields our freedom against such restrictions. When you buy or rent a computer containing GPLv3-covered software, the license protects your freedom to use modified versions of that software in your computer. GPLv2 always required that users be able to do this, but one of the improvements in GPLv3 ensures that the freedoms all GPL versions are meant to provide can't be taken away by hardware that refuses to run modified software.

When it comes to security measures governing a computer's boot process, GPLv3's terms lead to one simple requirement: Provide clear instructions and functionality for users to disable or fully modify any boot restrictions, so that they will be able to install and run a modified version of any GPLv3-covered software on the system.

Secure Boot is one such measure, defined by a UEFI standard, but discussion about it has primarily revolved around the rules established by Microsoft in its Windows 8 Logo program. These rules say what computer distributors have to do in order to have their systems be Microsoft-approved. Part of this includes implementing Secure Boot in specific ways.

In order to comply with Microsoft's rules as currently published, distributors of x86 computers will have to provide users both the option to customize Secure Boot by using their own security keys, and the option to disable it completely.

Secure Boot, done right, embodies the free software view of security, because it puts users -- whether individuals, government agencies, or organizations -- in control of their machines. Our thought experiment to demonstrate this is simple: Microsoft may be worried about malware written to take over Windows machines, but we view Windows itself as malware and want to keep it away from our machines. Does Secure Boot enable us to keep Windows from booting on a machine? It does: We can remove Microsoft's key from the boot firmware, and add our own key or other keys belonging to free software developers whose software we wish to trust.

So what's the problem?

In theory, there should be no problem. In practice, the situation is more complicated. As currently proposed, Secure Boot impedes free software adoption. It is already bad enough that nearly all computers sold come with Microsoft Windows pre-installed. In order to convince users to try free software, we must convince them to remove the operating system that came on their computers (or to divide their hard drives and make room for a new system, perceptually risking their data in the process).

With Secure Boot, new free software users must take an additional step to install free software operating systems. Because these operating systems do not have keys stored in every computer's firmware by default like Microsoft does, users will have to disable Secure Boot before booting the new system's installer. Proprietary software companies may present this requirement under the guise of "disable security on your computer," which will mislead new users into thinking free software is insecure.

Without a doubt, this is an obstacle we don't need right now, and it is highly questionable that the security gains realized from Secure Boot outweigh the difficulties it will cause in practice for users trying to actually provide for their own security by escaping Microsoft Windows.

It's also a problem because the Windows 8 Logo program currently mandates Restricted Boot on all ARM systems, which includes popular computer types like tablets and phones. It says that users must not be able to disable the boot restrictions or use their own signing keys. In addition to being unacceptable in its own right, this requirement was a reversal from Microsoft's initial public position, which claimed that the Windows 8 program would not block other operating systems from being installed. With this deception, Microsoft has demonstrated that they can't be trusted. While we are interpreting their current guidelines, we must keep in mind that they could change their mind again in the future and expand the ARM restrictions to more kinds of systems.

The best way out of all of this (other than having all computers come pre-installed with free software) would be for free software operating systems to also be installable by default on any computer, without needing to disable Secure Boot. In the last few weeks, we've seen two major GNU/Linux distributions, Fedora and Ubuntu, sketch out two different paths in an attempt to achieve this goal.

Fedora's approach

Fedora's default approach to official distribution has the project joining a Microsoft and Verisign developer program which will give them a key that can then be used to sign a "shim" bootloader. This shim loads GRUB 2, the GPLv3-covered GNU program whose job it is to boot the operating system kernel, in this case Linux. Because Fedora's key will be "vouched" by Microsoft, it will be recognized by the firmware on the vast majority of desktops and laptops available.

Fedora also suggests that others use this option for unofficial distribution of modified Fedora software, or any other free software operating system. Anyone can pay $99 and get their own Microsoft-backed key which they can then use to sign the software they wish to run and/or share.

Fedora is not requiring users to join the Microsoft program. Users can also create and use their own keys, with a little more work. The Microsoft program is the route they chose for official Fedora distributions, but they will also provide utilities and support for users wishing to work with their own self-generated keys.

There is much to like about Fedora's thinking, as explained by Matthew Garrett. Their process of deliberation evinced concern for user freedom; it's clear that the Fedora team sought a solution that would work not just for their own GNU/Linux distribution, but for as many free software users and distributions as possible. Their discussion was also mindful of the desirability of empowering users to sign and run their own modified software without being treated as second-class citizens. Unsurprisingly, with those concerns guiding their thinking, they have ended on a proposal which as described is compliant with GPLv3.

Unfortunately, while it is compliant with the license of GRUB 2 and any other GPLv3-covered software, we see two serious problems with the Microsoft program approach.

1) Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary -- so Fedora's shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft's key, official Fedora will no longer boot, as long as Secure Boot is on.

2) We reject the recommendation that others join the Microsoft developer program. In addition to the $99 expense being a barrier for many people around the world, the process for joining this program is objectionable. A nonexhaustive list of the problems includes: restrictive terms in multiple of the half-dozen contracts that must be signed, a forced commitment "to receive targeted advertisements and periodic member email messages from Microsoft," and a requirement to provide notarized proof of government-issued identification and a credit card.

These are not acceptable conditions for modifying or using your operating system. For the time being, we should instead rely on the approach Fedora will support for unofficial distribution -- providing tools and materials for users who want to install and use their own keys.

Software signed with self-generated keys has the downside of not working on the majority of computers right off the shelf, without the user taking some extra steps. We acknowledge that this is an issue, but in addition to insisting on (and contributing to) documentation to make the necessary process easy to follow, we will strive to solve this problem through political action against manufacturers and proprietary software companies who impede free software adoption. Encouraging free software distributors and users to trust Microsoft or any other proprietary software company as a precondition to exercising their freedoms is simply not an acceptable solution.

Ubuntu's approach

Ubuntu has also announced a plan which is further described in a message to the Ubuntu developers' mailing list. Their plan addresses software distributed through three different channels:

1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware. Additionally, they will be required by the certification guidelines to have the Microsoft key installed.

2) Ubuntu CDs, distributed separately from hardware, will also depend on the presence of Microsoft's key in the machine's firmware to boot, when Secure Boot is active.

3) Ubuntu bootloader images distributed online from the official Ubuntu archive will be signed by Ubuntu's own key.

In the first two situations, because of the requirement to have the Microsoft key, their approach has the same issue as Fedora's official method. Users have to trust Microsoft in order to boot official Ubuntu CDs. Their certification program amplifies this problem, because it means no one can sell certified Ubuntu machines without trusting Microsoft.

As with Fedora, on a system with Secure Boot properly implemented, Ubuntu users will be able to add their own keys, or Ubuntu's key.

Our main concern with the Ubuntu plan is that because they are afraid of falling out of compliance with GPLv3, they plan to drop GRUB 2 on Secure Boot systems, in favor of another bootloader with a different license that lacks GPLv3's protections for user freedom. Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system. This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.

Furthermore, addressing the threat of Restricted Boot by weakening the license of the bootloader is backwards. With a weaker license, companies will now have a form of advance permission to obstruct the user's ability to run modified software. Rather than work to make sure this situation does not happen -- for example by enforcing the proper Secure Boot implementation they say they "strongly support in [their] own firmware guidelines" -- Ubuntu has chosen a path which explicitly allows Restricted Boot.

No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue.

It is not too late to change. We urge Ubuntu and Canonical to reverse this decision, and we offer our help in working through any licensing concerns. We also hope that Ubuntu, like Fedora, will actively support users generating and using their own signing keys to run and share any versions of the software, and not require users to install a key from Canonical to get the full benefit of their operating system.

What's the FSF doing to help solve these problems?

Secure Boot raises many issues for protecting user freedom, promoting free software ideals, and encouraging free software adoption. Addressing it requires a multifaceted approach. Assessing the solutions popular GNU/Linux distributions have proposed is one aspect, but we will also take proactive measures of our own.

We will continue to build public support around our statement against Restricted Boot. Over 31,000 people and 25 organizations have signed this statement, pledging not to buy any computer that they cannot install a free operating system on, and to advise others to do the same. We were pleased last week to add Debian GNU/Linux as an official organizational supporter of the statement. Subsequently, Trisquel and gNewSense have also added their signatures. When further actions need to be taken to stand up for this freedom as Secure Boot and Restricted Boot are rolled out, we will call upon this base of support. If you haven't yet signed, please do.

We will fight Microsoft's attempt at enforcing Restricted Boot on ARM devices like smartphones and tablets. Like any other computer, users must be able to install free software operating systems on these devices. We will monitor Microsoft's behavior to make sure they do not deceive the public again by expanding these restrictions to other kinds of systems.

We will work with (and when necessary, pressure) manufacturers and distributors to make the user instructions for working with Secure Boot on all systems extremely clear, so that users will be able to disable it and modify the approved keys with little difficulty and no bias. We will also work to make sure that users can change all of the software running on their machine, including the boot firmware itself.

We will offer our licensing and compliance resources to any free software developers to help them make sure they are complying with the GPL and other licenses as they implement Secure Boot. We will monitor distributions of signed GPLv3 software to ensure that they respect the necessary user freedoms, including providing installation instructions and materials.

We have already started exploring ways in which the FSF can work with manufacturers on behalf of the entire free software community to make free software operating systems installable with default Secure Boot hardware settings.

We will continue to work with companies like Lemote, Freedom Included, ZaReason, ThinkPenguin, Los Alamos Computers, Garlach44, and InaTux to make computers available that are preinstalled with fully free GNU/Linux distributions.

We will help provide information about which computers and components are most compatible with free software, including making people aware of which machines have Restricted Boot. Much of this information will be found at http://h-node.org.

Conclusion and recommendations

What we've offered here is our position based on the details published by all parties involved so far -- we will continue to assess the situation as these plans are actually put into practice, or changes are announced.

Our focus is to evaluate proposed solutions to the issues posed by Secure Boot on the basis of how well they protect user freedom, to recommend the solutions that do the best job of that, and to stop attempts to turn Secure Boot into Restricted Boot.

The best solution currently available for operating system distributions includes:

1) fully supporting user-generated keys, including providing tools and full documentation for booting and installing both modified and official versions of the distribution using this method;

2) using a GPLv3-covered bootloader to help protect users against the dangers of Restricted Boot;

3) avoiding requiring or encouraging users to trust Microsoft or any company which makes proprietary software; and

4) joining the FSF and the broader free software movement in pressuring computer distributors to facilitate easy and independent installation of free software operating systems on any computer.

We will do what we can to help all free software operating system distributions follow this path, and we will work on a political level to reduce the practical difficulties that adhering to these principles might pose for expedient installation of free software. The FSF does want everyone to be able to easily install a free operating system -- our ultimate goal is for everyone to do so, and the experience of trying out free software is a powerful way to communicate the importance of free software ideals to new people. But we cannot in the name of expediency or simplicity accept systems that direct users to put their trust in entities whose goal it is to extinguish free software. If that's the tradeoff, we better just turn Secure Boot off.

Please support the FSF's work in this area by joining as a member or making a one-time donation.

______________

Copyright © 2004-2012 Free Software Foundation, Inc.

This work is licensed under a Creative Commons Attribution-No Derivative Works 3.0 license (or later version) — Why this license?.


  


FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj | 474 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
The only real solution
Authored by: Anonymous on Monday, July 02 2012 @ 01:50 PM EDT
The only real solution to this problem is to give the consumer ultimate control
over the signing keys in the computer. Without this, even Windows-only users
cannot have security. Eventually, a signing key *will* be compromised. That
cannot be avoided. Under Microsoft's plan, the user will be helpless to delete
this compromised key --- but the "bad guys" who have access to it will
not be able to attack their computers. The end user *must* have the ability to
delete a compromised key and replace it with a secure one. Otherwise,
"secure boot" does nothing for security.

[ Reply to This | # ]

Corrections thread
Authored by: nsomos on Monday, July 02 2012 @ 02:29 PM EDT
Post corrections here.

Thnx -> Thanks

[ Reply to This | # ]

Reaction from the European Commission
Authored by: Anonymous on Monday, July 02 2012 @ 02:54 PM EDT
Sooner or later someone is going to file a complaint with the European Commission regarding Secure Boot. It is clear that MS is using this as nothing more than a mechanism for restricting people's choice, in this case making sure that the "choice" is MS only. This is the sort of thing that the European Commission will take a very dim view on, particularly since MS has already been weighed and definitely found wanting!

The only question is: when will the complaint be filed.

Oh yes, and just before the inevitable comments: MS cannot "buy" it's way out of EC trouble. They are reputed to have tried that before, and it simply dropped them in it even deeper.

[ Reply to This | # ]

The channel
Authored by: Anonymous on Monday, July 02 2012 @ 03:03 PM EDT
In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.
I don't see how this helps. Canonical is supposed to be relieved that their distributors will have to deal with it instead?

It seems that FSF just agreed that GPL3 means that the key has to be provided. Just as Canonical's lawyers determined.

Let's hope that secure boot goes away for other reasons.

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: Anonymous on Monday, July 02 2012 @ 03:17 PM EDT
"in addition to being the primary interpreter of the license in
question"

The court is the primary interpreter of the license in question. In respect of
any given piece of software, third parties are entitled to rely on the wording
of the license actually used. The views of the drafter of the license are of
only peripheral interest, and of no especial legal value. Equity used to vary
with the length of the Lord Chancellor's foot. The GPL does not vary with the
length of Richard Stallman's.

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: PolR on Monday, July 02 2012 @ 03:21 PM EDT
We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.
I can't talk for Canonical but I wonder if this scenario is that much different from Canonical perspective. If I understand their business model, the maker of a Ubuntu Certified computer is a client of Canonical. Why would Canonical put this burden on their client? They may have a unspoken objective of not imposing this burden on their clients by fear of losing them.

Of course a principled stance that the user of the computer must be free will be welcome by the FOSS community. I hope Canonical will take such a stance. But I am afraid business objectives may be interfering here.

[ Reply to This | # ]

OT here
Authored by: PolR on Monday, July 02 2012 @ 03:29 PM EDT
You know the drill.

[ Reply to This | # ]

News picks here
Authored by: PolR on Monday, July 02 2012 @ 03:30 PM EDT
You know the drill for this too.

[ Reply to This | # ]

COMES here
Authored by: PolR on Monday, July 02 2012 @ 03:31 PM EDT
Thanks to the volunteers. This work still needs to continue.

[ Reply to This | # ]

Why Go Public?
Authored by: sproggit on Monday, July 02 2012 @ 03:36 PM EDT
This doesn't make any sense to me.

We're told that the FSF routinely has discrete [private] negotiations with
companies who have breached the terms of the GPL, as part of their on-going
mission to ensure compliance. As Eben Moglen said on occasions in the past,
there are numerous examples like this which never come to light, purely because
companies work with the FSF to comply.

This case is different. Canonical have taken a view which is [make no mistake]
contrary, but which *seems* [I have zero legal authority on which to base this
assertion] to be compliant with the GPL, just in a way that the FSF doesn't like
that much. Yet here the FSF has gone public.

I take no view on Canonical's course of action. For the purpose of this question
it's actually not relevant. But doesn't this public "naming and
shaming" [a trifle melodramatic, perhaps] do nothing to help?

[ Reply to This | # ]

Very carefully worded
Authored by: pem on Monday, July 02 2012 @ 03:37 PM EDT
As is everything from the FSF:

<blockquote>
This fear is unfounded and based on a misunderstanding of GPLv3. We have not
been able to come up with any scenario where Ubuntu would be forced to divulge a
private signing key because a third-party computer manufacturer or distributor
shipped Ubuntu on a Restricted Boot machine.
</blockquote>

Umm, yeah, but what about upgrades/updates? Surely the machine manufacturer
wants Ubuntu to support stuff afterwards...

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: Anonymous on Monday, July 02 2012 @ 03:50 PM EDT
"Why would the court ignore a promise made publicly? They own the copyright
and only them have standing to sue."

All of the states in the US will recognize equitable estoppel, and would not
ignore the views of the owner of the copyright if they amount to misleading
conduct, particularly deliberately misleading conduct.

But no sane distributor would rely on such an estoppel. They would have to
prove that they had relied on the statements giving rise to the estoppel
believing them to be true in a way which would cause them loss if the person
making the statement were to renege, had done so reasonably, and met the other
requirements of equitable relief (clean hands and so forth). As a sub-issue, it
is by no means clear that only the copyright in grub would be relevant here,
because of the mix of software ownership involved in booting up a computer.

This article is wrong and based on a misunderstanding of the law. Estoppel is a
discretionary relief available in equity for those who have acted in good faith
on the basis of statements made by other of dubious good faith. They are not
the basis of a business strategy.

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: Anonymous on Monday, July 02 2012 @ 04:02 PM EDT
Hey PJ, Isnt this the perfect opportuntity to draw parallels with Mono/.NET and

bash that a bit more?

[ Reply to This | # ]

Microsoft wants the razor/blade market
Authored by: Anonymous on Monday, July 02 2012 @ 04:31 PM EDT
I'm sure that what Microsoft wants do is turn the tablet market into the
razor/blade type of market. They have made it work for the XBox, and seen Apple
make it work for the phone/tablet markets. If the only way to buy software for
Windows 8 on ARM is through the Microsoft Store, then Microsoft can subsidize
the computer/OS purchase through revenues from the Microsoft Store. If Microsoft
wasn't a convicted monopolist, this might be reasonable.

If this is indeed Microsoft's plan, one way which would make everyone happy is
to charge more for an unlocked ARM model, or allow one to unlock the system
after the fact for a fee. While Microsoft would lose out on the blade sales,
they would be made whole on the razor sale. Users can then either get the
subsidized ARM model locked into Windows, or, if they want a different OS, pay
the unlocking fee which reimburses Microsoft for their subsidy.

[ Reply to This | # ]

MIssing the Point
Authored by: Anonymous on Monday, July 02 2012 @ 05:22 PM EDT

The FSF's argument misses the point. What Canonical are doing with a special "Ubuntu key" is to essentially allow the OEMs to bypass the "secure boot" by providing a loader that will load unsigned binaries. That lets the OEMs use the same motherboards and firmware as they ship for their MS Windows PCs, but just load a different key into it and use a hard drive with any Linux distro (not just Ubuntu) installed.

Disabling "secure boot" via a BIOS menu option is nothing but a bit of temporary sticky plaster. That option will probably disappear from standard firmware in future as older versions of MS Windows fall out of support and all supported versions have "secure boot".

Saying that "it's the PC OEM's problem" is a bit disingenuous. If an OEM has any sense, they will have a contract with Canonical that tosses the problem back in Canonical's lap. So, you sue the OEM, and they in turn sue Canonical (under contract law) demanding that Canonical come up with a solution. Canonical doesn't want to be in that situation.

Canonical tried working with the UEFI trade group (i.e. Intel and Microsoft) to address the root cause, but got nowhere. Where the blame really lies here is with Intel, who came up with this whole UEFI mess to begin with. People should be turning their flamethrowers on Intel and telling them to fix the mess they created.

Mathew Garret did a talk on UEFI which is on YouTube somewhere. If you can find it, it's a bit long, but well worth watching. What I find particularly interesting, is that UEFI is itself larger than the Linux kernel (if you exclude drivers from both). It's also extremely buggy, and there is no system in place for getting bug fixes out to users in the manner that operating systems have. It's also still running after boot. I will not be in the least bit surprised if UEFI becomes a target of malware writers much like Java and Flash are today. The overall effect may be to make PCs less secure, not more secure.

What I also found interesting is that Mathew Garret does not expect to see "secure boot" used on servers or virtualised systems, but rather just on consumer PCs. He didn't go into that in more detail, but I found that very peculiar. I would have thought the reverse more likely, but apparently not. It makes me wonder how much "secure boot" is really about security for the user, and how much it's really about sercurity for the media companies who want to turn PCs into consoles.

[ Reply to This | # ]

Im having trouble understanding the FSF position (as usual)
Authored by: Anonymous on Monday, July 02 2012 @ 06:20 PM EDT
They are so concerned about freedom .. very very concerned .. that they think
its is so important that Ubuntu are not allowed to choose which bootloader they
use?

"We stand for freedom .. at all costs"
"great ... I'l use this bootloader"
"no, you have to use a GPL3 one"
"but we told you, we dont like GPL3 .."
"burn the heretic! ... Mr Stallman, bring forth the rack!"

[ Reply to This | # ]

Solution for Microsoft and everyone else
Authored by: SpaceLifeForm on Monday, July 02 2012 @ 08:55 PM EDT
There is lots of SPIN out there about Secure Boot,
and how it is all about protecting the user from Malware.

That is the Big Lie.

You see, the Malware problem is basically a
Microsoft problem, created on purpose years ago
to lead the computing world to the current Big Lie.

It is all about, as I have written here years ago,
a scenario whereby the attackers create the problem,
and then come up with the 'solution'.

Here is my proposal to deal with this attack.

The hardware vendors that want to continue to stay
in bed with Microsoft, provides *TWO* different
firmwares (UEFI) for every machine they manufacture.

One firmware will boot using the Secure Boot mechanism.

The other firmware will ignore Secure Boot.

Windows can do a check to verify that it was booted
by the firmware (UEFI) that implements Secure Boot.
If Windows thinks it was not booted properly, it
can refuse to run.

The hardware vendor must supply a mechanism to flash
the non-Secure Boot firmware, *WITHOUT* requiring
Windows to do so. I.E., via a USB key or CD (the
UEFI firmwares are way too big for a floppy).
The UEFI code *MUST* properly boot CD, USB keys, USB floppy,
and netboot.

In fact, the user must also be able to go back to
the Secure Boot firmware so they can re-install Windows.

There can *NOT* be any dependency on Windows in order
to change the firmware from Secure Boot state to
non-Secure Boot state or the reverse.

The UEFI (either one), must be able to boot media
that allows the user to change the UEFI state from
Secure Boot to non-Secure boot *OR* the reverse.

If the user decides to go to non-Secure Boot, they
lose access to Windows software.

But they then can install a non-Windows OS.

Here is the tradeoff:

You will not be able to dual boot Windows and
other OSes on the same machine.

That seems to be a minimal issue in order to
preserve your freedom. If you want to, or have to
use Windows it will have to be a dedicated machine for Windows.

Now of course Microsoft will complain over this
solution, because it prevents them from controlling
the computing market long-term.

But, go ahead and complain Microsoft, and lets
see if Restraint of Trade kicks in.

But the bottom line, Microsoft, if the user wants
to not use Windows, the fine, you should not complain
about the hardware and firmware being able to run
a non-Microsoft OS.

Your complaint about protecting the user from malware
is moot.

If they run a non-Microsoft OS, it is not your
problem, and you have absolutely no grounds to worry
about any malware issues.




---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Snapback
Authored by: mexaly on Monday, July 02 2012 @ 09:41 PM EDT
When Windows is required, not optional, Microsoft loses the defense that the
owner is liable for choosing their buggy operating system.

Up until now, Windows has been an appliance. Use it or don't.

When it's required, it's a utility. Different laws apply.

(Oh, my, did someone say anti-trust? Or was that an echo?)

---
IANAL, but I watch actors play lawyers on high-definition television.
Thanks to our hosts and the legal experts that make Groklaw great.

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: symbolset on Tuesday, July 03 2012 @ 12:43 AM EDT
In my opinion this UEFI issue is just another attempt to lock all others out of
industry standard hardware. It's a very old theme, and getting wearisome.
Isn't it ironic that the purpose is allegedly security, but the first use the
thing is put to is to secure the PC against non-Windows software?

[ Reply to This | # ]

What about flashing the bios
Authored by: globularity on Tuesday, July 03 2012 @ 12:56 AM EDT
Would it not be possible to produce a signed bootloader and use that to load a
bios flash program then reflash the bios to jump over the offending code or
write a personal root key, I assume that this system does not use a hardware key
like the TPP. This approach was used in a few hacks for DVD firmware to skip the
region code check. A new checksum could be generated to suit the modified code
or the checksum code jumped over as well. If the bios uses the intel code there
should be a few signature bytes before the offending code which could be
searched for.

Not really a consumer hack but possibly a good way to make malware bios to serve
the user.

UEFI in general does not impress, a bloated bios is a bug haven and attack
vector in itself

---
Windows vista, a marriage between operating system and trojan horse.

[ Reply to This | # ]

Tivoisation of everything.
Authored by: Anonymous on Tuesday, July 03 2012 @ 04:50 AM EDT
When you think about it, how is this any different to what Tivo did?

Ignore who's pushing for what, and that Tivo distributed GPL software on their
locked-down system (That was a vector for dealing with it, nothing more), and
it's a bit blatently obvious that this is MS saying: "We want total control
over your hardware, and no, you don't have a choice!"

So, where's the anti-trust lawsuit?

[ Reply to This | # ]

UEFI is an attempt by Microsoft to lock out Linux from PCs and a fundamental attack on Freedom
Authored by: TiddlyPom on Tuesday, July 03 2012 @ 07:08 AM EDT
Microsoft acts as though all the hardware is Microsoft hardware. It isn't of course - the manufacturers are simply pre-loading Windows as a convenience. What Microsoft is TRYING to do is to prevent anybody loading an alternative operating system to Windows. That is a different matter and and they need to be stopped from doing this. UEFI gives Microsoft CONTROL over users - it could be used to STOP users running the software that they want to. It could (for instance) be controlled by a hostile government to prevent users from running anything other than a state sanctioned operating system. As such it is a fundamental attack on freedom.

UEFI BIOS is a road crash. It is possible to (effectively) brick a PC if you get it wrong whereas that is impossible with conventional BIOS. What we should be doing is to try and get the Linux friendly vendors to switch to CoreBoot which is much more Linux friendly. Come on IBM, AMD, Intel and others - you get lots of benefits from using Linux so how about some payback with helping to fund and extend CoreBoot.

Linux friendly companies (like System 76 which pre-load Ubuntu) tend to use traditional BIOS but should be looking at CoreBoot I think.

---
Support Software Freedom - use GPL licenced software like Linux and LibreOffice instead of proprietary software like Microsoft Windows/Office or Apple OS/X

[ Reply to This | # ]

How did Microsoft manage to hijack UEFI?
Authored by: Anonymous on Tuesday, July 03 2012 @ 08:19 AM EDT
This is for me the great mystery that I have not yet seen explained. The need
for UEFI was basically agreed to by some of the biggest names in computing so
how did we end up with this ludicrous situation of Microsoft now 'owning' UEFI
keys?

Bob

[ Reply to This | # ]

Just use longer Signature Chains
Authored by: Marc Mengel on Tuesday, July 03 2012 @ 11:20 AM EDT
Here's my thinking. What folks are talking about is a chain of signatures Sig(key,text) in the bootloader like:
Sig(MS,VK), VK, Sig(VK,Bootloader), Bootloader
That is, you have a vendor key VK signed by MicroSoft, and then your boot loader is signed by your vendor key.

But what you could have is something like:

Sig(MS,VMK), VMK, Sig(VMK,VK), VK, Sig(VK,Bootloader), Bootloader
So your Vendor Master key would be signed by MS, your Vendor key would be signed in turn by the Vendor Master Key, and then you would have the signed boot loader.

In principle then, you could have either MS's key OR the Vendor's master key (or both) in the firmware as a trusted key, and either one should let you boot the firmware, since they both appear in the signature chain. . If I read the slide deck from UEFI Summer Plugfest 2011[uefi.org] on page 10 of 28, it says that there is:

  • Complete X509 Certificate chain
  • Intermediate certificate support (non-root certificate as trusted certificate)
If those slides from UEFI are right, right you should be able to do this.

[ Reply to This | # ]

FSF Publishes Important Whitepaper on Secure Boot - Ubuntu Got It Wrong on Grub and GPLv3 ~pj
Authored by: Anonymous on Tuesday, July 03 2012 @ 11:33 AM EDT
I'm rather confused by the approach being used by FSF. From
what I can see, the three approaches described in the
article are:

1. What Fedora is doing. Complies with the GPL v3. Requires
trusting the key used by Microsoft. Can permit open source
software to be booted.

2. What Ubuntu is doing. Doesn't comply with GPL v3.
Requires trusting the key used by Microsoft and
additionally, requires an Ubuntu specific key. Can permit
open source software to be booted.

3. What the FSF is doing. Public education and bemoaning
anything that doesn't conform to their belief of how the
world should operate. Doesn't permit booting of open source
software unless performed on a machine that conforms to the
FSF belief of how the world should operate.

I don't know about the rest of the world, but I would
consider a priority being that I can actually boot and
install the OS of my choice on the machine of my choice.

Fedora seems to be dealing with the world as it currently
exists.
Ubuntu is following the Fedora approach, but with some
misunderstandings about the GPL.
FSF is still stuck in an Ivory Tower and not providing an
immediately workable solution and instead bemoaning that the
world isn't fair.

[ Reply to This | # ]

OT: RIP Andy Griffith
Authored by: Anonymous on Tuesday, July 03 2012 @ 12:16 PM EDT
Forgive me for being so far off-topic for Groklaw, but this
deserves a mention. For those (like me) who hadn't heard, Andy
Griffith has passed away this morning at 7:00 AM.

[ Reply to This | # ]

Dual booting no longer feasible?
Authored by: Anonymous on Tuesday, July 03 2012 @ 01:01 PM EDT
sgtrock, posting anonymously because I can't remember my password atm.

As I understand it, both RedHat's and Ubuntu's solutions assume a single OS
loaded on a PC. As a dual booter this is huge. Are we to be locked out of new
mobos in the future?

Since a fair number of people who run Linux desktops today are also dual
booters, isn't this a mistake by both companies? Don't they risk alienating a
number of influential voices?

Thoughts?

[ Reply to This | # ]

Is Microsoft being reasonable here?
Authored by: jbb on Tuesday, July 03 2012 @ 04:41 PM EDT
The FSF said:
In order to comply with Microsoft's rules as currently published, distributors of x86 computers will have to provide users[**] both the option to customize Secure Boot by using their own security keys, and the option to disable it completely.

IMO this is a very reasonable and responsible position by Microsoft. These are the two primary features that keep secure boot from being evil or becoming a Tivoization. I'm impressed that Microsoft would make them a requirement.

I'm not suggesting we let down our guard and assume these will always be a Microsoft requirement but I believe it is important for us to give credit where credit is due. I think a secure boot type system is inevitable. I also think it can be a good thing as long as it meets these two requirements. I'm happy to see that Microsoft seems to be coming down on the correct (open/free) side of this issue by ensuring that the owner of the machine has ultimate control over what software can run on the machine.


**I think the FSF and Microsoft mean (or should mean) owners not users.

---
Our job is to remind ourselves that there are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

The View from a Security Standpoint
Authored by: Anonymous on Tuesday, July 03 2012 @ 05:44 PM EDT
We don't want a machine that only runs software approved by them -- our computers should always run only software approved by us.

While a Data Center Manager at a large corporation, I learned that our security guidelines required that we reinstall the OS for any computer used on site. Mainframe, mini, workstation, PC - didn't matter. Trashed, zeroed, reinstalled, customized to our requirements.

Funny thing, the C trusted system requirements state that the system OS must be reinstalled, so that it is in a known state to the system owner at all stages.

I wonder why the large corporations aren't making more of a stink about this, let alone the government security bodies. Could they have changed their minds so radically?

artp, who has a todo list item to find his password, if only he could find his todo list....

[ Reply to This | # ]

FSF Publishes bland Whitepaper on Secure Boot
Authored by: Anonymous on Tuesday, July 03 2012 @ 06:58 PM EDT
I was unimpressed reading this article. My reading is the FSF saying "we wrote grub and ubuntu are dropping grub so we dislike ubuntu but like fedora who are going to use grub"

I don't think it adds much to the debate at all. As has been said elsewhere courts decide the law... not FSF. Ubuntu's statement implied that they have had legal advice and if that is so then they would be silly to ignore it.

Both Fedora's approach and Ubuntu's approach seem to be OK to me but obviously turning off secure/restricted boot is the only really sensible way forward.

Secure boot only really secures things for the key holder and that really means microsoft!

Anyway I was disappointed that the FSF have not really spent some time and had a more constructive/definitive statement of their position. As I say it strikes me of wooly thinking and sour grapes.

I'm surprised at PJ too. Perhaps groklaw can give us some guidance on the GPL3 issue in question rather than just repeat the FSF's bland statement.

Perhaps the real technical answer is a signed boot loader which disables secure boot and chain loads another boot loader.

Alex

[ Reply to This | # ]

Shuttleworth says...
Authored by: Anonymous on Tuesday, July 03 2012 @ 07:17 PM EDT
At
http://www.theregister.co.uk/2012/06/28/mark_shuttleworth_li
ve_chat/ right at the end,

Tom Dial asks:
"Based on the statement by FSF that the GPL V3 license on
grub2 would not require disclosure of Ubuntu private keys
for secure boot, will Ubuntu reconsider its approach to
that?"

and Mark Shuttleworth replies:
"SFLC advice to us was that FSF could require key disclosure
if some OEM screwed up. As nice as it is that someone at FSF
says they would not, we have to plan for a world where
leaders change, institutional priorities change. FSF wrote a
license that would give them the rights to take specific
actions, hard for them to argue they never would!"

[ Reply to This | # ]

How GPL V3 works
Authored by: Ian Al on Wednesday, July 04 2012 @ 02:09 AM EDT
If you fail to observe the GPL V3 licence then the copyright holder can sue you under the copyright law for copyright violation.

The FSF owns the copyright to GNU Grub 2. Actually, the licence is called the GNU General Public License and the FSF also own the copyright to that, as well.
This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.
In other words, the lawyers who wrote the GPL V3 cannot see any way that they would be able to sue the Linux distributions or the computer distributions for their copyright violations on GPL V3 relating to its use on a Restricted Boot Machine. They have made an official legal statement to that effect.

If the owners of the Grub 2 copyright and the owners of the GPL V3 copyright make the legally binding statement that they cannot sue you for using Grub 2 on a Restricted Boot Machine where, exactly, is the legal danger coming from?

---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

FSF version of grub2
Authored by: Anonymous on Wednesday, July 04 2012 @ 06:37 AM EDT
I realise it doesn't address the difference of opinion between the FSF and
Canonical, but what is to stop the FSF releasing their own, signed version of
GRUB2 which they could make available for anyone to use ?

[ Reply to This | # ]

Microsoft as "Super Apple" as FOSS Quibbles On the Sidelines
Authored by: Anonymous on Wednesday, July 04 2012 @ 07:39 AM EDT
In looking at both the FSF doc and the comments here, it seems to me that if
nothing else Microsoft using its monopoly power to hijack UEFI does two things.
First it essentially becomes "Super Apple," forcing everyone but the
tech savvy to run Microsoft's OS of choice, Windows 8, on any hardware
manufactured after a certain date. Microsoft controls the OS and the hardware
not already controlled by Apple, leaving the average consumer with a choice
between the 95% monopoly and the 5% proprietary OS. Second, Microsoft's tactic
fragments the FOSS community in a very serious way.

But as someone who is not a lawyer but is a Linux user I'm sitting here
scratching my head and wondering where the lawsuits are. Does no one have
standing to sue to stop this thing in its tracks? Why are FOSS people wasting
time backbiting each other instead of teaming up and taking on Wintel directly
in the legal arena? I would like to see that issue addressed clearly in Groklaw
in general and specifically in the comments here.

[ Reply to This | # ]

Ideal solution
Authored by: Anonymous on Wednesday, July 04 2012 @ 07:43 AM EDT
The best solution would be to have a trustworthy independent
organisation which handled the root key. Not Microsoft, which
is what seems to be happening now. Then Ubuntu, Red Hat,
Microsoft etc, would all be in the same situation. Validating
your personal key would need to be free, so that anyone could
make changes to an OS. I'd like to see a public registry too,
with names and details.

[ Reply to This | # ]

Microsoft executives asked for this lockout capability
Authored by: darkonc on Saturday, July 07 2012 @ 04:48 PM EDT
I remember there being an e-mail from within Microsoft where an executive asked for the ability to redefine the bios in such a way that they could lock customers out of loading Linux. Now, a number of years later, we have them implementing precisely that capability.

Does anybody else remember that email -- do you know where I could find it in the archives (either here or elsewhere)?

---
Powerful, committed communication. Touching the jewel within each person and bringing it to life..

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )