All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking)
Date: Sun, 26 Dec 2010 22:55:20 +0100	[thread overview]
Message-ID: <4D17B9C8.8080301@gmail.com> (raw)
In-Reply-To: <201012262115.oBQLFpQL072419@m5p.com>

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

On 12/26/2010 10:15 PM, ehem+grub@m5p.com wrote:
>> 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.
>
>   
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

  parent reply	other threads:[~2010-12-26 21:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17  5:19 Two Small Patches (x86 VolId & Sun Label Checking) ehem+grub
2010-12-25 17:34 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-26  5:29   ` ehem+grub
2010-12-26 10:41     ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-26 21:15       ` ehem+grub
2010-12-26 21:17         ` ehem+grub
2010-12-26 21:55         ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-12-29  6:25           ` ehem+grub
2010-12-29  8:21             ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-30  7:11               ` ehem+grub
2010-12-29 19:54           ` Brendan Trotter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D17B9C8.8080301@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.