Windows applications making GRUB2 unbootable

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

by mtigas • 16 years ago

55 33 16 years ago

chiark.greenend.org.uk

mtigas• 16 years ago

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...

jacquesm5• 16 years ago

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.

aw3c22• 16 years ago

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

__david__3• 16 years ago

The application shouldn't be doing what it's doing, but it still is kind of hypocritical to complain that someone else is doing exactly what grub is doing. There is no reason grub couldn't make a little partition for its data (except for inconvenience). It wouldn't even have to know how to parse a partition to get to its data, it would just be there to mark the area on the disk as its own.

We've solved the problem of data contention on a disk a long time ago...

ilkhd2• 16 years ago

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).

athom2• 16 years ago

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...

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?

sid03• 16 years ago

Not if you give the process administrator privileges.

athom2• 16 years ago

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...?

aw3c22• 16 years ago

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

sid03• 16 years ago

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.

jrockway2• 16 years ago

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• 16 years ago

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.

Hoff• 16 years ago

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.

sandGorgon• 16 years ago

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.

pilif2• 16 years ago

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• 16 years ago

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.

woodall2• 16 years ago

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.

naner• 16 years ago

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

Windows applications making GRUB2 unbootable

Related Stories