grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two Small Patches (x86 VolId & Sun Label Checking)


From: Brendan Trotter
Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking)
Date: Thu, 30 Dec 2010 06:24:01 +1030

Hi,

2010/12/27 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 12/26/2010 10:15 PM, address@hidden wrote:
>> Quite simple, the disk slice scheme detection routines vary in the
>> quality of their detection. In particular, the MSDOS-style detection is
>> *extremely* brittle. The only even mildly distinguishing characteristic
>> it finds is ensuring only the msb of the boot-flag byte is set. The other
>> thing it looks for is the 0xAA55 signature, but that is merely a signal
>> to PC-BIOSes that the disk is bootable; as such *any* bootable disk for a
>> IBM-PC will have that signature, whether or not it is actually using the
>> MSDOS-style header. A 1 in 65536 chance of a false positive is bad.

If a disk is bootable then it should have the 0xAA55 signature,
regardless of whether or not there's a partition table.

If a disk is *not* bootable then it should *not* have the 0xAA55
signature, regardless of whether or not there's a partition table.
Lots of OSs (including Linux/fdisk) have the same stupid bug where
they put the 0xAA55 signature on pure data disks where it doesn't
belong. The worst case here is that the computer crashes during boot
if the disk ever becomes the "first" disk (rather than the BIOS moving
on to the next type of bootable device, and/or rather than the user
getting a "No OS found" BIOS error message), so it's usually just an
annoying bug (and not a serious bug, unless someone is perverted
enough to attempt to use a bootable CD-ROM or something as a type of
fail-safe in case their first drive goes missing), but it's still
"wrong".

To check if there is/isn't an "MBR partition table", first check for
GPT. If there's no GPT then; for each (potential) MBR partition table
entry that isn't "type = unused" check for "(boot-flag & 0x7F == 0)"
then check if the starting CHS address is sane (e.g. not an invalid
sector, and with work-arounds for "unrepresentable") and if the ending
CHS address is sane (e.g. not invalid and not less than or equal to
the starting CHS, and with work-arounds for "unrepresentable") and
then do the same for the starting and ending LBA addresses. Then you
could check for overlapping partitions.

If a partition is marked as "active" then you could check for the
0xAA55 signature in the first sector of that partition, but that is
the only case where checking the 0xAA55 signature makes any sense.

> Actually 1 in 2^(7*4+16) =2^44 in you take into account the both checks
> and consider every possible sector equiprobable.

Actually, if you take into account that the second check is worthless
and/or wrong; then for the current code; if there's 4 (assumed)
"usable" partitions there's 1 chance in 4*127 of thinking there's a
partition table when there isn't, and if there's only one (assumed)
"usable" partition then it drops to 1 chance in 127; and if the MBR
contains random data the former is much more likely than the latter (I
was too lazy to do the calculation properly).


Cheers,

Brendan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]