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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking)
Date: Sun, 26 Dec 2010 22:55:20 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101211 Icedove/3.0.11

On 12/26/2010 10:15 PM, address@hidden wrote:
>> From: Vladimir '?-coder/phcoder' Serbinenko <address@hidden>
>> On 12/26/2010 06:29 AM, address@hidden 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.
>
>   
Actually 1 in 2^(7*4+16) =2^44 in you take into account the both checks
and consider every possible sector equiprobable. While this is a
problem, it's design problem of this partitioning label. More sanity
checks are possible but they would be heuristics and increase the
possibility of false negative. So every additional sanity check is to be
considered on case-by-case basis.
> 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.
>
>   
Recent GRUB don't reject multiple disklabels per disk and you can access
all the partitions described by all of them. E.g:
(hd0,msdos1) vs (hd0,sun1)
While false-positive looks ugly in ls and slows GRUB down (checking for
filesystem in ghost partitions) it's only mildly affected. False
negatives on the other hand may prevent GRUB from booting altogether
> I do have a specific goal in mind. Perhaps oddball, but a definite goal.
>
>
>   
Improving quality of partmap detection is a good goal but be aware of
the price of heuristics.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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