Re: grub-probe detects ext4 wronly as ext2

[Javier Martín]

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