Re: grub-probe detects ext4 wronly as ext2

[Javier Martín]

El vie, 04-07-2008 a las 02:08 +0200, Robert Millan escribió:
> On Thu, Jul 03, 2008 at 07:07:55PM +0200, Javier Martín wrote:
> > > 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,
> 
> You mean because grub-probe is not conservative enough when determining 
> whether
> a filesystem can be accessed?  I think we agreed that this needs fixing.
Indeed, grub-probe should adopt the most conservative stance possible so
that real GRUB works on minimum assurances. However, I meant reliability
was compromised because grub-probe, as currently used by grub-install on
i386-pc, only checks the availability of the filesystem GRUB will boot
from. Thus, if GRUB is installed on a normal ext2/fat/whatever partition
and the OS kernel we will boot (or another file we want to use) is
stored in an ext4 partition, the most likely output of our current
scheme is an error from the ext2 driver (ranging from an error message
to a crash), because in its current best-effort policy it ignored the
"forbidden" signs in the superblock and tried to read the ext4 partition
as ext2.

> 
> > and
> > as I already explained, it will be unreliable as long as the filesystem
> > drivers use the "best-effort" politics you support.
> 
> If grub-probe says "you can't rely on this filesystem being readable by
> GRUB", then we're bound to that.  You don't make it any more reliable by
> adding user input into the equation.
As I said, there are setups in which (the current use of) grub-probe
does not add any reliability, because it just checks the GRUB boot
partition, not those with the kernels we might load (and I'm not
proposing instituting such checks).

> 
> When I talk about real GRUB being "best-effort", it's not reliability that
> is at stake here;  we already got that from grub-probe.  This is a minor
> problem IMHO;  it's just about having read access to as many filesystems
> as possible (other than the one we need for booting) vs not risking
> corruption during data read.  I seriously think we're wasting our time
> here.  Really, it's not worth it.  This whole discussion is not about how
> we engineer a new feature or solve a bug, but about how we deal with a
> _temporary_ limitation in our code.
It is both a temporary limitation and a permanent one: the limitation of
not being able to read ext4 extents and such is temporary indeed, but I
already said why we cannot just ignore the "incompat" field. Today is
ext4, tomorrow it will be something else. As I mentioned above, such
flags are huge warning signs telling us not to dare enter the partition
if we don't know what to do with them.

> 
> > 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.
> 
> Because it's a gratuitous increase in complexity of the user interface.  It's
> a choice about a bug, which is due to be fixed, and for which an informed
> answer will always be the same.
As I said before, we can fix the "ext4 compatibility not implemented"
bug, we WILL eventually encounter _another_ "incompatible" feature, and
then another... We can't be in par with the evolution of extN
filesystems!

> 
> > > 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.
> 
> When the problem is you've read corrupt data, and you have to handle this
> gracefuly, it doesn't make any difference that it was your fault because
> you violated a spec, it's still the same problem.
Fine, then. Let's _not_ worry about automatically trying to read what we
cannot, violating standards and such. After all, GRUB _is_ better than
Internet Explorer. It _does_ make a difference because we can avoid it
being our fault if we just obey the huge warning signs in the
superblock! If the user specifically requests us to try and read the
partition even though the superblock tells us not to, then we proceed
and whatever happens is, at least in part, his fault, even though this
does not completely exonerate us for not having a completely up-to-date
filesystem driver.

> > I'm finding this discussion increasingly unproductive
> 
> Hey, at least we agree on something :-)
> 
As I threatened in my last post, here is the full patch, with the
incompatible features detection and the user override option, for a
total of +168 bytes in i386. It works like this (test was on a QEMU VM,
with GRUB booting from floppy and hda1 being an ext2 part turned ext4):
        grub> ls (hd0,1)/
        error: unknown filesystem
        grub> set ext2_options=ignore_incompatible
        grub> ls (hd0,1)/
        lost+found/ grub/ Godfather.wav vmlinuz-2.6.24-16-server (&more)
        grub> linux (hd0,1)/vmlinuz-2.6.24-16-server
                [Linux-bzImage, setup=0x2a00, size=0x1e26d8]
        grub> hexdump (hd0,1)/Godfather.wav
        (shows 256 bytes of zeros instead of the actual contents)
Of course, the new file (with extents) was the Godfather tune, while the
kernel was an old extentless file. Trying to "play" the file crashed
QEMU (I suspect that meant a triple fault happened in the simulation?)

That was it. I will post no more in this thread. Do whatever you please
with the patch - I'll just request some more people from the GRUB dev
team to review the thing, instead of the tennis match we've had here
(and I appreciate all matches, even the ones I lose).

signature.asc
Description: Esta parte del mensaje está firmada digitalmente