grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guidance on conflicts between GNU GRUB and proprietary software


From: Colin Watson
Subject: Guidance on conflicts between GNU GRUB and proprietary software
Date: Thu, 23 Sep 2010 23:19:24 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Richard,

We've had some (amicable!) disagreements in the GRUB development team
regarding a question of how far we should go out of our way to avoid
conflicts with certain types of mainly proprietary software, and
Vladimir Serbinenko, our current maintainer, suggested that I ask you
for guidance.

http://lists.gnu.org/archive/html/grub-devel/2010-08/msg00137.html
offers a rough outline of the root of the issue, although not of all the
ensuing discussion.  I seem to remember that you often don't have
convenient web access, so I'll try to summarise here.


On systems using MBR partition tables, GRUB generally makes use of the
boot track (sectors 1-62) to store some of its code, as well as the boot
sector itself.  In GRUB Legacy, this was Stage 1.5; in GRUB 2, this is
core.img.  In either case, it contains enough code to read the remainder
of GRUB from an ordinary filesystem.  There are alternatives to this
strategy: we could embed core.img in reserved space at the start of a
filesystem instead, except that the most common filesystems in current
use don't provide enough space for us; or we could store core.img (or
Stage 2 in GRUB Legacy) as an ordinary file and hardcode its disk
offsets, and indeed we do this in some situations where there's no other
choice.  This tends to be fragile, though, in that filesystem repair
operations and the like could mean you have to reinstall your boot
loader, so we encourage people to embed core.img in the boot track
wherever possible.

Unfortunately, the use of the boot track was never really very clearly
defined by any of what pass for the standards in the MBR world.  The
GRUB developers of course tend to take the position that it should be
obvious that the boot track is owned by the boot loader, but others have
taken different positions.  From time to time, we get bug reports of the
general form "I boot Windows and then GRUB doesn't start any more", and
there often ensues an argument about just whose fault it is.  We've been
getting these reports rather more now that GRUB 2 is being widely
deployed, because GRUB 2's core image is somewhat more featureful than
GRUB Legacy's Stage 1.5 and is thus a few sectors larger, increasing the
probability of problems.

It appears that, rather than the operating system itself being at fault,
a number of Windows applications take over a sector in the boot track
and store bits and pieces of data there.  These applications include
"licence managers" (for which I have precious little sympathy, as
they're trying to enforce proprietary licences in sneaky ways by making
it hard for uninstallation tools to operate properly) and certain backup
and recovery tools.


Along with some others who e-mailed me when I blogged about this issue,
Vladimir suggested that GRUB should use an error-correcting code to
protect itself: codes such as Reed-Solomon can be implemented in not
much space, and storing two extra sectors of data would allow us to
correct an entire corrupted sector.  We have no disagreement here; I
think it's a good idea to make this critical area of code as robust as
reasonably possible.

I proposed that we spend a little time assembling (on a best-effort
basis) a list of signatures of foreign software using the boot track.
It's straightforward for grub-setup to notice that one of the sectors it
needs matches a particular signature, and to write the core image in
such a way as to avoid it; in fact I was pleased to find that this
didn't require changing the boot sector and hard disk bootstrap assembly
code at all!  I have posted a complete working patch for this containing
a handful of known signatures, which needs only to be fleshed out with
some more signatures gathered from users having this kind of trouble;
and I have been working on gathering this information from bug reports.
This is where our disagreement arises.


Vladimir's position, as stated on IRC today, is that:

  * Trying to avoid sectors in this way goes beyond simply protecting
    ourselves, yielding territory that ought to be ours.  In some sense,
    it recognises the legitimacy of the other software in question.

  * It is only worth doing this if the companies producing this software
    give a valid justification.  If they get in contact with us to do
    so, then we should be able to find a better way to collaborate
    anyway.

  * Users may even welcome our inadvertent interference with the time
    counter on some piece of proprietary software ...

My position (and I'm sorry that this is unbalanced because I've gone to
more length - perhaps Vladimir can expand on his) is that:

  * Regrettably, given that I see no practical alternative, I think our
    own justification for using the boot track isn't quite as absolutely
    solid as we'd like to think, given the lack of standardisation; it's
    a manifest fact that we're not the only children trying to play in
    this sandpit.

  * It's not clear that all the companies doing this are using the boot
    track as a tool to restrict users' freedom, even though some
    certainly are.  Some of the programs known to cause issues are
    backup and recovery tools, and I can imagine reasonable if arguably
    misguided reasons for them to want to store data outside any
    partition; maybe I'm naïve but it seems more likely that their
    purpose is purely technical rather than to restrict freedom.

  * The fact that this problem occurs with increased probability when
    using GRUB 2 vs. GRUB Legacy means that some users have gone back to
    GRUB Legacy to avoid this problem, commonly saying something like
    "you must have changed something in GRUB 2 to cause this; why don't
    you put it back the way it was?".  As a GRUB 2 developer who finds
    the new source base an order of magnitude more hackable and
    maintainable than the old, I want to fix any reason why somebody
    would feel they needed to use GRUB Legacy.

  * Most importantly, I feel that this is a situation where insisting on
    our total ownership of the boot track may be self-limiting.  Some of
    the programs appear to be popular ones with many users who genuinely
    want to use them despite their non-freedom, and they've been known
    to get upset when their sector in the boot track vanishes, to the
    point where users have to reinstall the program in question; for
    people with dual-boot systems this is a severe problem.

    On one hand, this casts proprietary software in a bad light: it's
    the awkward thing you have to reinstall all the time.  Searching the
    web for anecdotes I do find some more thoughtful users taking this
    position.  On the other hand, their proprietary software only breaks
    when they install free software, and many users don't think through
    the reasons behind that.  I'm concerned that this casts us as the
    villain: we look like the vandals who break things, and when we
    aren't involved there's no problem.  I find it difficult to defend
    our rightness when we're not the ones sitting there with a broken
    system.


There are various technical arguments to be made, but I think the core
issue under dispute is an ethical/strategic one: to what extent should
free software go out of its way here to avoid inadvertently limiting its
usefulness due to conflicts with proprietary software?  Are we setting
an undesirable precedent if we come down on one or other side of this,
or should this kind of thing be considered case-by-case?  We'd value
your comments on this.

Thanks,

-- 
Colin Watson                                       address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]