linux-ext4 - Re: [PATCH 1/4] vfs: vfs-level fiemap interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080914180843.GA31649@infradead.org>
Date:	Sun, 14 Sep 2008 14:08:44 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Theodore Tso <tytso@....EDU>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	akpm@...uxfoundation.org, Mark Fasheh <mfasheh@...e.com>,
	mtk.manpages@...il.com
Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface

On Sun, Sep 14, 2008 at 02:01:32PM -0400, Theodore Tso wrote:
> On Sun, Sep 14, 2008 at 09:47:11AM -0400, Christoph Hellwig wrote:
> > On Sat, Sep 13, 2008 at 02:49:24PM -0400, Theodore Ts'o wrote:
> > > +* FIEMAP_EXTENT_NO_BYPASS
> > > +Direct access to the data in this extent is illegal or will have
> > > +undefined results.
> > 
> > This one is sitll misnamed and for sure utterly misdocumented.  Direct
> > access to the data is always illegal and has undefined results, and
> > programs that do it anyway (e.g. grub) are in really deep trouble.
> 
> Programs like Grub *have* to.

Depends on which grub you mean.  Grub that boot loader has a filesystem
driver and accesses it, that's fine.  /usr/sbin/grub, the installation
program doesn't have to.  In fact the only reason why it does is to
"verify" that blocks are in place.  This breaks down depending on the
phase of the moon, but especially badly on filesystems using a different
address space than the block device one.

> And in the case of a boot-loader, Lilo
> and Grub have been able to do so safely for over 15 years.

I think your arguing 100% profs my point that the flag name and
description are utterly confusing.  What lilo does is load a kernel
from an offset into the partition.  This is obviously fine, and a
perfect use case for an extent map / block map interface.  I think
(but not one could clarify to me) that this is the primary use case
of the no bypass flag, which is supposed to tell lilo that this extent
is not actually a real block but some sort of meshup and lilo should
return an error that it gets.  But this flag is totally unrelated
to beeing able to bypass the filesystem driver when running the kernel
which is always bogus, and has caused endless amounts of trouble with
the only widespread tool that does it (/usr/sbin/grub).

> The name isn't particularly important, but what it indicates is very
> clearly useful.

Sometimes I really wish people would read email before replying to them.
I did not say anywhere that this flag (at least for the use case I think
it is which no one even bothered to document) is good, but the name
and description are utterly wrong, and misleading.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html