Re: [RFC] Detect other software using embedding area
On Tue, Aug 31, 2010 at 2:54 PM, Thomas Schmitt scdbac...@gmx.net wrote: Maybe one should use external boot media of which GRUB can claim complete ownership. I.e. an USB stick or a CD which hosts GRUB and a custom configuration. This way, GRUB would have no shares in the embattled area at all. This way, GRUB would be unusable on rack-mounted servers in data centers. You can't add a USB stick or CD there, if all you have is remote serial console access... -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On Sun, Sep 5, 2010 at 10:14 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Tue, Aug 31, 2010 at 2:54 PM, Thomas Schmitt scdbac...@gmx.net wrote: Maybe one should use external boot media of which GRUB can claim complete ownership. I.e. an USB stick or a CD which hosts GRUB and a custom configuration. This way, GRUB would have no shares in the embattled area at all. This way, GRUB would be unusable on rack-mounted servers in data centers. You can't add a USB stick or CD there, if all you have is remote serial console access... On servers hopefully you are setting up a special partition for grub to use. The embedding area sounds like it is trying to solve a problem with dual-boot systems where the first OS is already installed and cannot be moved. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] Detect other software using embedding area
Every so often people report that booting Windows renders GRUB
unbootable. This is usually because some Windows application writes to
a sector in the embedding area (or boot track), so that application
and GRUB end up fighting with each other on alternate boots. I've begun
to gather information about these applications, as there don't seem to
be very many of them, and I propose that we do something like the
following to defend ourselves against problems and to try to avoid
causing problems in our turn.
On the applications in question: some of them are licence managers,
and I'm unsympathetic towards these, since their use of the boot track
is solely to try to enforce their proprietary licences in a way that
can't easily be worked around by uninstallation tools, but the effect of
this is also to impinge upon users' rights to back up and restore their
system without unreasonable amounts of effort. However, some of the
applications are backup and recovery utilities, and may well have a
better justification for storing data outside a partition, although I
can't easily tell exactly what they're doing.
When I blogged about this recently (and rather unexpectedly ended up on
Slashdot), several people followed up to say that GRUB shouldn't be
using the embedding area because it was never defined to be used for
anything in particular and has no protocol for arbitrating among
conflicts like this. Sometimes I even replied to them, depending on how
polite they were about it ... They're not entirely wrong; GRUB is
skating close to the edge of the lack-of-specification here. However,
all the alternatives have severe problems too, and you get to choose
what set of things you'd like to break:
* Simply loading core.img from a filesystem using blocklists has
obvious problems when the filesystem decides to rearrange blocks
during fsck, defragmentation, etc.
* Most filesystems don't reserve enough space near the start for us to
be able to insert core.img safely there (although we should make
better use of the ones that do; but grub-devel is not a filesystem
development list and there's only so much we can fix).
* Most people who suffer from problems like this are on dual-boot
systems, where the free OS is not the first one to be installed, and
in that situation it's not unusual for the BIOS to be unable to
address disk space after that occupied by the first OS. Automatic
partitioners can't safely move the first OS to make room for a boot
partition at the start, so many people will in practice need GRUB to
be placed before the first partition.
I'd like to avoid having another argument about that here. This patch
is solely to try to work around the problems with our current setup in a
way that makes as few changes as possible. Maybe in ten years we'll all
be using GPT and won't have to worry about it.
Some people have also suggested that GRUB should use an error-correcting
code such as Reed-Solomon when embedding core.img. This is an
interesting idea and it might be worth doing in the future. However, it
doesn't fully solve the problem at hand because GRUB would still be
overwriting sectors used by these other applications, some of which are
very popular and people actually do want to use. We won't do ourselves
any favours by appearing to be a poor citizen.
2010-08-31 Colin Watson cjwat...@ubuntu.com
* util/i386/pc/grub-setup.c (embed_signatures): New array.
(setup): When embedding the core image in a post-MBR gap, check
for and avoid sectors matching any of the signatures in
embed_signatures.
=== modified file 'util/i386/pc/grub-setup.c'
--- util/i386/pc/grub-setup.c 2010-08-19 11:24:00 +
+++ util/i386/pc/grub-setup.c 2010-08-31 10:19:46 +
@@ -63,6 +63,33 @@ static const grub_gpt_part_type_t grub_g
#define grub_host_to_target32(x) grub_cpu_to_le32(x)
#define grub_host_to_target64(x) grub_cpu_to_le64(x)
+struct embed_signature
+{
+ const char *signature;
+ int signature_len;
+};
+
+/* Signatures of other software that may be using sectors in the embedding
+ area. */
+struct embed_signature embed_signatures[] =
+ {
+{
+ /* ZISD */
+ .signature = ZISD,
+ .signature_len = 4
+},
+{
+ /* FlexNet */
+ .signature = \xd4\x41\xa0\xf5\x03\x00\x03\x00,
+ .signature_len = 8
+},
+{
+ /* FlexNet */
+ .signature = \xd8\x41\xa0\xf5\x02\x00\x02\x00,
+ .signature_len = 8
+}
+ };
+
static void
setup (const char *dir,
const char *boot_file, const char *core_file,
@@ -85,7 +112,7 @@ setup (const char *dir,
char *prefix = NULL;
char *tmp_img;
int i;
- grub_disk_addr_t first_sector;
+ grub_disk_addr_t first_sector, es;
grub_uint16_t current_segment
= GRUB_BOOT_MACHINE_KERNEL_SEG + (GRUB_DISK_SECTOR_SIZE 4);
grub_uint16_t last_length = GRUB_DISK_SECTOR_SIZE;
@@ -400,15 +427,95 @@ setup (const char *dir,
assert
Re: [RFC] Detect other software using embedding area
Hi, Colin Watson wrote: [...] embedding area [...] (setup): When embedding the core image in a post-MBR gap, [...] Aka hidden blocks ? several people followed up to say that GRUB shouldn't be using the embedding area because it was never defined to be used for anything in particular and has no protocol for arbitrating among conflicts like this. A valid point. All participants invite trouble. but grub-devel is not a filesystem development list and there's only so much we can fix). Maybe one should use external boot media of which GRUB can claim complete ownership. I.e. an USB stick or a CD which hosts GRUB and a custom configuration. This way, GRUB would have no shares in the embattled area at all. Main development task would be to allow easy creation and manipulation of the boot media. As frontend of grub-mkrescue ? Would ISO 9660 multi-session be suitable for changing GRUB configuration on CD ? A new session would be added with a new set of volume descriptors (superblock) and a new directory tree. Plus new or changed files. Does GRUB know it has to mount the first track of the last session on CD/DVD/BD media ? (I assume it knows when it deals with MMC media.) We won't do ourselves any favours by appearing to be a poor citizen. How about GRUB offers to become the umpire of the playfield ? I.e. to have on the external media: - GRUB - copies of the MBR and embedded area of each involved operating system - a feature which puts one of those copies onto hard disk according to menu choice of the user and then boots the copied MBR. - a feature which copies found MBR and embedded area onto external media or remote systems. I am not educated enough to know whether GRUB already allows to copy data from its boot media to disks. Actually i have a gzpLinux CD with custom SSH setup which allows me to boot my test machine and to restore backups of MBR + embedded area remotely from my workstation. This allowed me to switch between GRUB and boot loaders of FreeBSD and OpenSolaris before i found out how to make GRUB boot those other systems. (My GRUB is hosted by a Debian system.) To have a complete GNU/Linux as umpire is appealing to me. So eventually GRUB development should consider to adopt an existing rescue system for that purpose. This system could then update its own GRUB configuration. (It would be interesting to make it add a new session to its own boot CD :)). Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On Tue, Aug 31, 2010 at 02:54:58PM +0200, Thomas Schmitt wrote: Colin Watson wrote: but grub-devel is not a filesystem development list and there's only so much we can fix). Maybe one should use external boot media of which GRUB can claim complete ownership. Most people want their system to be able to boot using the hard disk alone. Obviously experts can set up something different, but it would be pretty hopeless to say that you need a writable CD or USB stick to boot your newly installed GNU/Linux system. Obviously feel free to look into this separately, but I would ask that you please start a new thread if you wish to do so as it does not really solve the problem at hand, which is a real problem for many of our users. Thanks, -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On Tue, Aug 31, 2010 at 4:28 PM, Colin Watson cjwat...@ubuntu.com wrote:
+struct embed_signature
+{
+ const char *signature;
+ int signature_len;
+};
+
It seems this cannot take care of cases where signature starts at some
byte offset in a sector, isn't it?
--
bvk.chaitanya
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On Tue, Aug 31, 2010 at 07:15:17PM +0530, BVK Chaitanya wrote:
On Tue, Aug 31, 2010 at 4:28 PM, Colin Watson cjwat...@ubuntu.com wrote:
+struct embed_signature
+{
+ const char *signature;
+ int signature_len;
+};
It seems this cannot take care of cases where signature starts at some
byte offset in a sector, isn't it?
Correct. If I see such a signature in practice then I'll extend it. ;-)
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
Hi, On Tue, Aug 31, 2010 at 8:28 PM, Colin Watson cjwat...@ubuntu.com wrote: When I blogged about this recently (and rather unexpectedly ended up on Slashdot), several people followed up to say that GRUB shouldn't be using the embedding area because it was never defined to be used for anything in particular and has no protocol for arbitrating among conflicts like this. Unfortunately, where the PC BIOS is concerned a lot of things are de facto standards, rather than actual standards; but I've always held a far simpler view: The MBR and the remaining sectors in the first track (before the start of the first partition) are reserved for the sole use of the boot manager. If GRUB is the boot manager, then no OS (and no application running under any OS) has the right to touch these sectors; and the opposite is also true - e.g. if GRUB is not the MBR (e.g. GRUB is chain-loaded by something else) then GRUB has no right to touch any of these sectors. If applications running on Windows are causing problems (overwriting something they have no right to touch), then the best solution would be a public web page (maybe in the GRUB wiki?) that explains the problem and lists which applications are buggy/broken crap... Cheers, Brendan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On 08/31/2010 05:36 PM, Brendan Trotter wrote: Hi, On Tue, Aug 31, 2010 at 8:28 PM, Colin Watson cjwat...@ubuntu.com wrote: When I blogged about this recently (and rather unexpectedly ended up on Slashdot), several people followed up to say that GRUB shouldn't be using the embedding area because it was never defined to be used for anything in particular and has no protocol for arbitrating among conflicts like this. Unfortunately, where the PC BIOS is concerned a lot of things are de facto standards, rather than actual standards; but I've always held a far simpler view: The MBR and the remaining sectors in the first track (before the start of the first partition) are reserved for the sole use of the boot manager. If GRUB is the boot manager, then no OS (and no application running under any OS) has the right to touch these sectors; and the opposite is also true - e.g. if GRUB is not the MBR (e.g. GRUB is chain-loaded by something else) then GRUB has no right to touch any of these sectors. I completely agree with this point of view. If applications running on Windows are causing problems (overwriting something they have no right to touch), then the best solution would be a public web page (maybe in the GRUB wiki?) that explains the problem and lists which applications are buggy/broken crap... List of such software would be a good thing. However relying on it as the sole solution supposes that the user is concious and searches the real reason. However this expectation however logical it seems is completely irrealistic given our userbase. Cheers, Brendan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
