From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWxwf-0000bv-Sr for mharc-grub-devel@gnu.org; Sun, 26 Dec 2010 16:16:01 -0500 Received: from [140.186.70.92] (port=45189 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWxwd-0000bl-3j for grub-devel@gnu.org; Sun, 26 Dec 2010 16:16:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWxwb-0005zw-Sr for grub-devel@gnu.org; Sun, 26 Dec 2010 16:15:59 -0500 Received: from 207-172-210-101.c3-0.hdp-ubr1.sbo-hdp.ma.static.cable.rcn.com ([207.172.210.101]:51062 helo=mailhost.m5p.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWxwb-0005zl-Pa for grub-devel@gnu.org; Sun, 26 Dec 2010 16:15:57 -0500 Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id oBQLFpSZ090686 for ; Sun, 26 Dec 2010 16:15:56 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.14.4/8.13.7/Submit) id oBQLFpQL072419 for grub-devel@gnu.org; Sun, 26 Dec 2010 13:15:51 -0800 (PST) Message-Id: <201012262115.oBQLFpQL072419@m5p.com> In-Reply-To: <4D171BBC.9000506@gmail.com> To: The development of GNU GRUB Date: Sun, 26 Dec 2010 13:15:51 -0800 (PST) Sender: ehem@m5p.com From: ehem+grub@m5p.com X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sun, 26 Dec 2010 16:15:56 -0500 (EST) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 21:16:00 -0000 >From: Vladimir '?-coder/phcoder' Serbinenko > 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 O- _____ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0