El jue, 03-07-2008 a las 16:02 +0200, Robert Millan escribió: > 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. 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 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 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. > > 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? 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 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 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. > 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? It would, on a perfect world, but making all the FS driver routines 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.
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
