Windows applications making GRUB2 unbootable(chiark.greenend.org.uk)
chiark.greenend.org.uk
Windows applications making GRUB2 unbootable
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html
9 comments
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.
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...
We've solved the problem of data contention on a disk a long time ago...
Grub is not operating within the OS sandbox though.
Why does that give it a free pass to write to places on the disk that are "reserved" or unallocated?
Grub may not operating within an OS sandbox, but it is required to play nicely with the OSes it is booting. The way to do that is to wrap your data in a partition or a file.
Grub may not operating within an OS sandbox, but it is required to play nicely with the OSes it is booting. The way to do that is to wrap your data in a partition or a file.
It doesn't give it a free pass but there is no 'supervisor' to stop it.
Well, you're right that grub-the-bootloader doesn't have a supervisor to stop it from writing to random places on the disk (since it's not running under an OS), but grub-the-bootloader doesn't actually write to those sectors, so I'm not sure what your point is.
grub-the-comman-line-utility writes to those sectors but it runs in linux userspace so it's really in the same position as the windows programs that also write to the reserved space...
grub-the-comman-line-utility writes to those sectors but it runs in linux userspace so it's really in the same position as the windows programs that also write to the reserved space...
It runs in user space, indeed. As root.
I do agree that the OS "should" not allow access but it has to because otherwise you would not be able to modify it.
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.
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.
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.
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.
Exactly - how else would you install Grub otherwise? :)
An installer or a program running at installation time as the super user has different permissions than just any old application.
Think about it, if an application can write to the boot area then you've got a giant hole in your security.
Think about it, if an application can write to the boot area then you've got a giant hole in your security.
This gapping hole has actually been used to target TrueCrypt.
http://www.stoned-bootkit.info/
http://www.h-online.com/security/news/item/Bootkit-bypasses-...
http://www.anti-forensics.com/modify-truecrypt-encryption-bo...
http://www.stoned-bootkit.info/
http://www.h-online.com/security/news/item/Bootkit-bypasses-...
http://www.anti-forensics.com/modify-truecrypt-encryption-bo...
Right, but how do you do disk imaging (for example) if the OS doesn't give you access to the entire drive? The OS could say "OK, you can modify any drive's boot area but the one I'm on", but that doesn't help if you're booting from another drive and using chainloading.
Hell, you can flash motherboards from an OS... writing to the boot area is just one example of many 'giant holes in your security'.
Hell, you can flash motherboards from an OS... writing to the boot area is just one example of many 'giant holes in your security'.
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?
Oh proprietary software vendors. Won't you ever learn that you can't stop "unauthorized use" on general-purpose hardware?
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.
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.
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.
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.
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.
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.
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.
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.
Clearly the solution is to use a boot floopy.
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.
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.
[deleted]
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.
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.
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?
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?
Not if you give the process administrator privileges.
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...?
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...?
The installer is what is probably writing to the unpartitioned space.
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.
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.
I think the right solution would be to publicise and shame the culprit applications.
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.
The bootloader is a single point of failure -- for it to rely on unspecified behaviour is absurd.
So what happens when one of these applications overwrites the signature of another? Does the latter stop working?
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).
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...