

Windows applications making GRUB2 unbootable - mtigas
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html

======
mtigas
See also
[https://encrypted.google.com/search?q=DRM+writes+to+boot+sec...](https://encrypted.google.com/search?q=DRM+writes+to+boot+sector)

This is a pretty nasty thing that's largely coming to light _just now_ because
GRUB2 uses a significantly larger portion of the space between the MBR and
first partition ("embedding area," 24KB vs 10KB).

What we have is separate applications (GRUB2 and whatever Windows application)
trying to use off-spec storage (the "embedding area") at the same time. Seems
to be a bad idea on everyone's part, not just the GRUB or rogue Windows app
developers.

The "embedding area" is not guaranteed to exist, be a certain size, or be
unused:
[https://encrypted.google.com/search?q=embedding+area+is+unus...](https://encrypted.google.com/search?q=embedding+area+is+unusually+small)

~~~
jacquesm
I think the application is clearly at fault here. The boot loader doesn't have
to make any assumptions about the disk (not even the presence of files or a
filesystem), it sets up the info passed on to the operating system and both
the operating system _and_ any applications within that OS should stay outside
of areas that were not explicitly allowed. The OS should never allow an
application to do this.

~~~
aw3c2
I do agree that the OS "should" not allow access but it has to because
otherwise you would not be able to modify it.

~~~
rbanffy
No OS can block users with administrative privileges from completely
destroying their environments.

That said, no application without a very high level of trust (perhaps above
what an Administrator can do on Windows) should be able to write _outside_ the
filesystem. This should, at the very least, pop-up some "Program X is about to
do something remarkably stupid. Allow or deny?" dialog.

~~~
j_baker
I'd be suprised if windows _didn't_ show such a dialog. The user probably just
ignored it because they see such dialogs all the time.

~~~
Raphael_Amiard
Be surprised then. This thing happened to me (on windows 7). I'm very wary
about what kind of dialog i click on to, and never saw a warning which would
seem related to that.

------
jrockway
Sounds like it's time to write a Windows driver that redirects all writes like
this to a regular file. That way, apps keep working transparently, and their
clever DRM scheme fails miserably.

Oh proprietary software vendors. Won't you ever learn that you can't stop
"unauthorized use" on general-purpose hardware?

~~~
tomjen3
Ah but you can make it sufficiently difficult that people will pay for the
legal version rather than take the time to download it and find a legal crack.

If it takes 3 months for a hot game to be cracked, you loose very few sales.

And yes, pirates will purchase the games if you make them difficult enough to
crack.

------
pilif
So. This is one software writing into a reserved area of a drive and then
complaining about another piece of software that does the same.

Granted. One is for booting an operating system, the other for DRM purposes.
But both are doing stuff they should not, so IMHO there's not much reason for
complaints.

edit: I notice that I'm getting downvoted. Care to explain why? That embedding
area isn't something you are supposed to write data to.

Now, some software out there still does it (grub2, truecrypt and various DRM
solutions unser windows), but that doesn't give the maker of one software the
right to blame the maker of another piece of software for writing there.

Both should find a better solution, but this certainly isn't a bug in either
software - both work around the specification and are getting bitten.

~~~
spicyj
The problem is that when a user installs an application like Photoshop, he
doesn't expect it to change anything outside of the operating system partition
that it's being installed on because it has absolutely no right to be anywhere
else.

In contrast, a bootloader like GRUB2 inherently works at a much lower level
than user applications and is expected to modify certain things on the hard
disk that would not belong to any operating system because it can assume
(almost always) that it is the only bootloader on the disk.

~~~
woodall
_when a user installs an application like Photoshop, he doesn't expect it to
change anything outside of the operating system partition_

This still does not make it right for GRUB et al. to call claim to that area
of the hard disk. If anyone can write to it, for what ever their needs may be,
then forethought should have said, "hey, this can potentially screw some stuff
up. We should find a BETTER way". I use GRUB as my primary bootloader and I
still cannot get on their side in this debate.

~~~
jrockway
Clearly the solution is to use a boot floopy.

~~~
pilif
While that would indeed work, I'm sure there must be a better way.

One that always works is to put all the grub stuff into its own primary
partition and make that one bootable.

Of course that would greatly complicate the installation process, but maybe
grub can reuse some of the work that was done for parted.

If grub was in its own partition, the likelihood of it being broken by third
party software is much lower. What could happen is that some software resets
the boot partition flag, but that's easily restored.

In case of EFI, if I understand correctly, you can even mark any file on any
partition bootable (blessing the file is the term, I think), which makes it
even easier.

------
sandGorgon
This might not be entirely Microsoft's problem.

I faced similar issues with Dell's backup/restore software for windows 7,
which I multiboot with Ubuntu.Still others had this issue with HP backup and
recovery manager

The relevant bug is here -
<https://bugs.launchpad.net/debian/+source/grub2/+bug/441941>

What is interesting is that Grub apparently doesnt have a problem, but Grub2
does.

I got rid of it simply by uninstalling any bundled software (Dell, HP, Sony,
Lenovo) BEFORE installing Linux.

------
athom
Intuit took some heat for this back around 2001~3, thereabouts. One article on
the subject can be found here:

[http://www.geek.com/articles/news/turbotax-installer-
destroy...](http://www.geek.com/articles/news/turbotax-installer-destroys-non-
windows-partitions-20030214/)

I'm kind of surprised there's software still doing this, and shouldn't Windows
and its new and improved security have put an end to these kinds of
shenanigans on its side?

~~~
sid0
Not if you give the process administrator privileges.

~~~
athom
Which you should never do. An application package's installer might need those
priveleges, but the bookkeeping application itself should not.

Speaking for myself, I make a point of not running applications with
administrator priveleges, except those which have a clear reason. My preferred
virus scanner is one example. Installers are another, but Intuit's behavior
leaves me much more reluctant to trust a vendor-supplied installer.
Fortunately, I don't think those are so necessary, these days...?

~~~
sid0
The installer is what is probably writing to the unpartitioned space.

------
Hoff
The web server is overrun, and the article accordingly inaccessible.

I implemented a system for an OS bootstrap that uses a scheme similar to this,
though I deliberately placed the boot partitions "underneath" (carefully
double-mapped) files within the file system that were expressly created for
the purpose of "protecting" the boot-level structures from the OS and its disk
activities.

The files were located over specific ranges of disk blocks that were known to
the console; so long as that mapping was maintained, everybody was happy.

That change would require changes to a few OS-level tools; to (for instance) a
Linux partition or Windows. (I had that option.)

The other approach is to place the boot structures in a boot partition; to use
one of the four slots available in MBR for a partition for the boot tools.

The consoles I was working with support EFI (and which has its areas of brain
damage) and console makes allocating a GRUB2 boot partition trivial. That
keeps the console and its tools from stomping on the partitions, and the
applications from stomping the boot loader.

If you're stuck back in BIOS-land with MBR (and no easy way to launch into
EFI), there's likely no good solution to these collisions other than grabbing
an MBR slot, as there's almost certainly no general Windows coordination
policy here other than "don't do that".

Microsoft Windows itself has occasionally and classically stomped on foreign-
format disks; it had the galactic stupid of writing a "harmless" signature to
disks it didn't find MBR structures on. If the console pilot allowed Windows
to write that "harmless" signature and your foreign file system was corrupted.

------
aw3c2
I think the right solution would be to publicise and shame the culprit
applications.

~~~
sid0
The right solution is to stop acting outside the specs and have the meat of
the bootloader in a (possibly separate) partition. The term "embedding area"
seems to be entirely made up by the GRUB developers -- I couldn't find a
single reference to it outside GRUB-related mailing lists and blog posts.

The bootloader is a single point of failure -- for it to rely on unspecified
behaviour is absurd.

------
naner
So what happens when one of these applications overwrites the signature of
another? Does the latter stop working?

------
ilkhd2
Agree. Right solution would be something akin to BootMagic, which stores the
code in a separate small partition. Or, as a half-measure the can use code
compression (LZ77 or similar).

