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: ehem+grub
Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking)
Date: Wed, 29 Dec 2010 23:11:20 -0800 (PST)

>From: Vladimir '?-coder/phcoder' Serbinenko <address@hidden>
> On 12/29/2010 07:25 AM, address@hidden wrote:
> >> From: 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.
> >>>       
> >   
> >> 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.
> >>     
> > Alas, seeing how every possible sector is very much *not* equiprobable,
> >   
> Then you need to havethe information about distribution before even
> speaking about any probabilities. Otherwise these "probabilities" are
> good only for fortune-telling.

Brendan Trotter did some additional demolition. The real problem is those
extra bits are all set to *zero*. Unused space in most schemes will
likely be cleared to zero, so those are fairly likely to fall by default.
If they overlap structures, then the odds will vary.

Using the SunOS-style for comparison, since I've got samples handy. The
overlaps are on the start cylinders for slices #0, #2, #4, and #6. Of
those, #2 will almost certainly be zero (overlap slice, covering the
whole disk) and #0 will very likely be zero as often being the root FS.
#4 and #6 are more interesting, that is the 2nd least significant byte,
so they're fairly likely to have data there. Though not too many systems
will have six or more genuine slices, so #6 is pretty likely to go unused
and it will be left as zeros. So, only seven bits are semi-likely to be
notable.

Jumping to the real world. My fast example passed, though it reads as
completely empty to MS-DOS. Two other samples got lucky, both had lots of
slices and so hit both of the magic bytes. On the flip side, one only had
two bits set so it was pretty close...


> > Organizational item here. Is the existing layout of <task>/<arch> for the
> > best? (task would be boot/partmap/parttool, arch is pretty much every .c
> > file in grub-core/partmap) I wonder if perhaps a structure like
> > <arch>/<task> would work better?
> >
> >   
> Shuffling the files around without anything more than "it looks slightly
> better for me" is usually useless. We, the current developpers, find the
> current layout convenient. If do-o-cratically the consensus on changing
> of layout would be established it can be done, however I don't see it happen

It keeps associated structures closer together. Specifically, it means
things like the boot blocks for MS-DOS-style partitions
(grub-core/boot/i386) would be closer to the code for handling
MS-DOS-style partitions (grub-core/partmap/msdos.c,
grub-core/parttool/msdos.c). Seeing how all of those share some internal
portions that no other code cares about, it would seem keeping them
closer together would be a good thing.

Anyway, it isn't crucial for my purposes, I thought I'd suggest it, but
I can readily deal with it either way.


> While the sensible checks would be accepted, pushing tolerances of
> heuristics is of little use. Tell the real stuff if you want to convince me

Have I mentioned heuristics in any of my messages? I've merely been
writing that the existing methods are rather sub-optimal. The checks for
MS-DOS-style partitions will pretty much accept any old garbage, while
most of the other schemes have got pretty good exclusion checks.


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





reply via email to

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