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

[ehem+grub@m5p.com]

>From: Vladimir '?-coder/phcoder' Serbinenko <phcoder@gmail.com>
> On 12/26/2010 06:29 AM, ehem+grub@m5p.com wrote:
> > I will in fact be implementing breaking detection functions into distinct
> > functions uniformly,
> I'm not fond of "let's change it just because we can". There are much
> more real tasks on the project. Come to #grub and I'm sure will find
> something for you.
> >  because there is a deeper issue lurking here. Looks
> > to be pure luck no one ran into an unpleasant bug lurking in the existing
> > design.
> >
> >   
> Please show me the real problem then.

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.

Whereas most of the other schemes have actual magic numbers for the
disk-slice scheme, that is *not* merely a flag for whether it is okay to
boot from or not (plus checksums, which push them to 1 in 2^32 chance of
incorrect detection).

Take a look at the attached file, it is ment as a header for a 512KB
image (`dd if=/dev/zero count=1023 2>/dev/null | cat sample /dev/stdin >
full_sample`). The only reason it will be correctly detected as a
SunOS-style disk label is that routine gets tried first, the MSDOS-style
detection would take it as valid.


I do have a specific goal in mind. Perhaps oddball, but a definite goal.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM@gremlin.m5p.com PGP F6B23DE0         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0