From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KEPOl-0005Uc-JF for mharc-grub-devel@gnu.org; Thu, 03 Jul 2008 10:02:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KEPOj-0005SX-Vg for grub-devel@gnu.org; Thu, 03 Jul 2008 10:02:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KEPOf-0005MN-2T for grub-devel@gnu.org; Thu, 03 Jul 2008 10:02:57 -0400 Received: from [199.232.76.173] (port=56155 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KEPOe-0005M8-Tk for grub-devel@gnu.org; Thu, 03 Jul 2008 10:02:52 -0400 Received: from aybabtu.com ([69.60.117.155]:45278) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KEPOe-0004Qm-CL for grub-devel@gnu.org; Thu, 03 Jul 2008 10:02:52 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KEPKi-0005C8-Hj for grub-devel@gnu.org; Thu, 03 Jul 2008 15:58:49 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KEPNz-0005Ew-Gi for grub-devel@gnu.org; Thu, 03 Jul 2008 16:02:11 +0200 Date: Thu, 3 Jul 2008 16:02:11 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080703140211.GA19341@thorin> References: <4868C017.8040004@isaac.cedarswampstudios.org> <1214827937.9353.43.camel@localhost> <20080701160827.GF6985@thorin> <1214929545.13432.19.camel@dv> <1214937759.9353.64.camel@localhost> <20080701204816.GA31206@thorin> <1214954927.9353.91.camel@localhost> <20080702142245.GA21064@thorin> <1215027160.9353.125.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1215027160.9353.125.camel@localhost> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub-probe detects ext4 wronly as ext2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2008 14:02:58 -0000 On Wed, Jul 02, 2008 at 09:32:40PM +0200, Javier Martín wrote: > El mié, 02-07-2008 a las 16:22 +0200, Robert Millan escribió: > > On Wed, Jul 02, 2008 at 01:28:47AM +0200, Javier Martín wrote: > > > > A --ignore-incompatible flag doesn't sound like a nice thing to do; it means > > > > we're passing our own problem to the user instead of solving it. > > > We don't have any "problem" to pass to users: ext4 is not supported > > > > We don't have an urge to support ext4, but that doesn't mean we shouldn't > > consider it a problem. > > > > I think adding an interface for the user to choose in which way to deal with > > our limitations is a nasty thing. I strongly object to that. > May I ask why? Is it thus better to impose our own way of dealing with > our limitations, unchangeable and possibly wrong in some instances (see > below for a possible scenario)? Sensible defaults are good, but choice > is one of the bases of freedom. We're never in a position in which we can impose things, because GRUB is free software to begin with, and anyone can modify it to better suit their needs. The question here is whether we should increase complexity with interfaces that don't provide any usefulness to the user, just to make it easier to do potentially dangerous things. If a user understands the implications and really doesn't mind making her system bootability unreliable, then she should have no problem modifiing the source to do it. > The problem with INCOMPAT_* flags is that we cannot always know what > they mean, and thus, a "best-effort" reader risks not just bumping into > metadata it does not understand (and thus crashing or spitting thousands > of errors if it's not robust enough), This should never happen; see the remark about corrupt filesystems in my previous mail. > but also ignoring it and reading > wrong data to memory. This looks like a more general problem. I wonder if we should really address it at the filesystem level. e.g. the filesystem could be perfectly fine but the files in it went corrupt; if the data you're reading is corrupt, does it matter at which point it was corrupted? A more elegant solution (also may be interesting for security at some point) would be for update-grub to hash each file it generates access commands for and embed the sum in grub.cfg as a check parameter, like if verify_hash /file xxxxx ; then do_something_with_file /file fi So, if we take for granted those two things: - That GRUB should never crash no matter what you feed to it. - That update-grub instructs GRUB to verify file consistency via hashing. does this address all of your concerns? -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.)