Re: Guidance on conflicts between GNU GRUB and proprietary software

[Lennart Sorensen]

On Thu, Sep 23, 2010 at 11:19:24PM +0100, Colin Watson wrote:
> 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.

Well perhaps grub could keep a list of known cases to look for and warn
the user if it sees one and perhaps suggest using the crappy blocklist
method instead if they insist on keeping their license manager or whatever
the problem cause is.

I personally think the software that writes to the disk outside a
filesystem should be banned and shunned, but just because I don't run
any doesn't mean other people don't.

Making grub more robust sounds nice, even if it is just to ensure you
can still boot in case of disk read errors.  Working even if some stupid
software does something it shouldn't, well that's just a bonus.  The
detection and avoidance is certainly debateable, although "do no harm"
would probably be appreciated by users of multiple operating systems on
their machines, so aborting a grub-install if a conflict is detected and
suggesting a (crappy?) workaround of using the blocklist instead saves
the user some hassle.

I wonder what those license managers do on a GPT partitioned disk.
I guess on those grub would be either in an EFI system partition or in
a bios boot partition, and in neither case would it be in unpartitioned
space.

-- 
Len Sorensen