From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KESHn-0001Pm-Mo for mharc-grub-devel@gnu.org; Thu, 03 Jul 2008 13:07:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KESHl-0001MI-KP for grub-devel@gnu.org; Thu, 03 Jul 2008 13:07:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KESHk-0001K0-CP for grub-devel@gnu.org; Thu, 03 Jul 2008 13:07:56 -0400 Received: from [199.232.76.173] (port=60923 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KESHk-0001Jh-0M for grub-devel@gnu.org; Thu, 03 Jul 2008 13:07:56 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]:34102) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KESHj-0005tF-CV for grub-devel@gnu.org; Thu, 03 Jul 2008 13:07:55 -0400 Received: by ug-out-1314.google.com with SMTP id l31so977013ugc.48 for ; Thu, 03 Jul 2008 10:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=lbw+e+S08JS6BZaI9IWxFJqU01pucAGVSgMk5tXbsl0=; b=AQoq/yNaQyhlpgLkv/3gq+KpNcNJmCMk0RAZK3r5bY9AjcTqOhIC+kcYrKIGnktCPS V1QpHRT9TEcCDL4vykuWlc7gJ+56/tGyi5DVtexF5WtVVxd+LxWR9Dfad6vh/WC/2F3t VDRcv61rdknTU1ZpAlpGwvnbl3zuJiaAs9UeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=R+xt5u4JiFOfSG+Jw/B4rr5AFxgWnu/9mabNsL+yv8CVyYXLjbRHHYAR3gc150RfPO 7ZXUPoLnxvAWbnkoE9IfujMOtRe/z1BtW0/rs+qV8ujt9QGdu6Jxqm/7vW647K5yi2fY hPcUBcUL38LNTqvDpG2vWptJBK9mhhDq93GjM= Received: by 10.78.148.15 with SMTP id v15mr140283hud.44.1215104872030; Thu, 03 Jul 2008 10:07:52 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id 18sm551984hue.17.2008.07.03.10.07.49 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Jul 2008 10:07:50 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <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> <20080703140211.GA19341@thorin> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uqNBWcKCfA++sT1ZDmt2" Date: Thu, 03 Jul 2008 19:07:55 +0200 Message-Id: <1215104875.8123.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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 17:07:58 -0000 --=-uqNBWcKCfA++sT1ZDmt2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El jue, 03-07-2008 a las 16:02 +0200, Robert Millan escribi=C3=B3: > On Wed, Jul 02, 2008 at 09:32:40PM +0200, Javier Mart=C3=ADn wrote: > > El mi=C3=A9, 02-07-2008 a las 16:22 +0200, Robert Millan escribi=C3=B3: > > > On Wed, Jul 02, 2008 at 01:28:47AM +0200, Javier Mart=C3=ADn wrote: > > > > > A --ignore-incompatible flag doesn't sound like a nice thing to d= o; 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 > > >=20 > > > We don't have an urge to support ext4, but that doesn't mean we shoul= dn't > > > consider it a problem. > > >=20 > > > I think adding an interface for the user to choose in which way to de= al 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. >=20 > 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 nee= ds. GRUB is bundled with many Linux distros, and while it can be substituted for others, being the "default choice" should entail a bit of responsibility. Please, don't be like M$ with their "oh, if the users don't like us, they can always switch (after overriding lock-in)". > The question here is whether we should increase complexity with interface= s > 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 sh= e > should have no problem modifiing the source to do it. The system bootability is already unreliable with the current code, and as I already explained, it will be unreliable as long as the filesystem drivers use the "best-effort" politics you support. I'm just proposing that we change the default politics in the bootloader to "nearly conservative" and then having an user-controllable option to enable "best-effort" behaviour. I've had GRUB since at least 2004, and I've done a few nasty things in its command line from the start; but only now I feel comfortable enough to modify its source, so don't assume that a knowledgeable/advanced user will be brave enough to modify the source of his _bootloader_ just like that. I don't understand why you're so adamant against sensible defaults AND the possibility of a rational, free choice. > > but also ignoring it and reading > > wrong data to memory. >=20 > This looks like a more general problem. I wonder if we should really add= ress > 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, doe= s it > matter at which point it was corrupted? It does, if the data on disk is not corrupted and our filesystem driver reads wrong data because in its "best-effort" trials to read the data it forfeits the "specification"-mandated behaviour of aborting on finding incompatible feature flags. We would be INTRODUCING errors in the data, instead of just reading erroneous data because of a crash or something like that. > A more elegant solution (also may be interesting for security at some poi= nt) > would be for update-grub to hash each file it generates access commands f= or > and embed the sum in grub.cfg as a check parameter, like >=20 > if verify_hash /file xxxxx ; then > do_something_with_file /file > fi This is fine for update-grub, but the GRUB2 scripting language is complex enough that detecting every file access without missing any can get quite complex, and we'd need to embed even more code in the kernel (the hash verifier). I've implemented MD5 and SHA1 in various programming languages as a simple challenge and I can tell you that, while not the toughest thing in the world, it's not simple to get right and it means even less space in an already big core.img. =EF=BB=BF > So, if we take for granted those two things: >=20 > - That GRUB should never crash no matter what you feed to it. > - That update-grub instructs GRUB to verify file consistency via hashin= g. >=20 > does this address all of your concerns? =EF=BB=BFIt would, on a perfect world, but making all the FS driver routine= s tough enough to provably ensure that they will never crash no matter what is fed into them will probably enlarge the code size too much. WRT the proposed hashing, it does not take into account the use of the GRUB command line and, as I already mentioned, can also fail. I'm finding this discussion increasingly unproductive because it's drifting over an ideological issue (whether or not switch the reading policy to more conservative and give users an override over it), so I will not push the issue much further. I'll probably send in a new version of the patch with the "user override" option implemented within a few days and let the devs decide about it. --=-uqNBWcKCfA++sT1ZDmt2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASG0Ha6Sl+Fbdeo72AQLdEBAAuY1JqILIkG5wNuLVOf0v/cpRTrsUcQw9 bkPv/bmMwbKJHDqZV6/QA828OLZdlbg0WhMk7bXb461+tRyfsdsuIAoI66AunfVt 8YpqEcJxOIItlTqJjXtDn+ylT0dn8E+u0XcXLoMgl43uC/XHVQSGyQcYSZQCaVsi haJyml+XcoE1ucsip7M0x74rcypFQxL5U//k9+FEpvdxszGHZfR4sWNqSRJakazk CSbwzswu72z52QpRAOswKvm0ja4PVnCrfnBIe14F+aKnWDCxLifIxWoYZvv9oybm i+N14BM1nVBeVZJwAHtqZCpViz1KAADQ24RSLQL9U/1Oa5YP/rHdzL71+YJsey7e B6B2NUl1ArKsQSFu5okbp+YnkiTD5S5M0i0iWsOnF9blSBDT4KhzU/h1hL9gvsIW pdnQ71inNx9F0VVxxLocfRVdkCU9o1bJDiMhWVI5A1xlnQHMXwJKmupm58TQ9Nxh CKwfMBbYOJ5ZRZcL6Mhvv3Ys/8umGI5RwFngXB5YUTA9OTwD0q9tGRh0JQ/XQ3M5 kOgSSM5ToJlqwc2AoQ9C0jLOWFAkMubOwOdzj/+RTrX+sAJIwn7MinIKj2A6vKxH NYGdPmqVs5BvZVdjTpw5uPCDFN2LVjBAZmA7vzOwjeGSQ1fG7efQUtbjCi07wM6i A+rK4ZjxNcE= =tRZP -----END PGP SIGNATURE----- --=-uqNBWcKCfA++sT1ZDmt2--