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 [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
