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
<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
