linux-ext4 - Re: Minimal configuration for e2fsprogs

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: <20120627125443.GA32356@thunk.org>
Date:	Wed, 27 Jun 2012 08:54:43 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	linux-ext4@...r.kernel.org
Subject: Re: Minimal configuration for e2fsprogs

On Wed, Jun 27, 2012 at 09:21:17PM +1000, Tony Breeds wrote:
> 
> Calling perror/exit from this deep in a library doesn't seem right to me I
> think a better option would be to change rb_get_new_extent()
> to return an errcode_t and pass that up the call chain.  I'm happy to do
> that.  If I read rb_insert_extent() correctly I can simply return if
> rb_get_new_extent() failed, as nothing as been changed at this point
> you've only traversed the rb tree.  The problem is that very few of the
> callers of rb_insert_extent() actually check the return value :( so this
> patch will be a little bigger than I'd like.

Well, rb_insert_extent() isn't returning an error; it's returning
whether or not it needed to insert an extent or not.  And the bigger
problem is there's no way to return an error all the way up the
callchain, since it ultimately gets called by functions like
ext2fs_mark_block_bitmap() which never contemplated that the function
might fail.

So there really is no way to return an error at this point, and if you
fail allocating memory, we're kind of doomed anyway.  We could replace
this with an abort(), but there's really not much else we can do here.

I suppose, more generally, we could add a new callback which gets
called on memory allocation failures; although in practice, the place
where we are most likely to run into trouble is e2fsck, and we already
have sufficient debugging code there thanks to e2fsck/sigcatcher.c.
So maybe just using an abort() is the best approach for now.

> The qsort calls scare me a little.  I expect that bad things would
> happen if the directory block wasn't sorted.  So just providing a
> qsort() in yaboot that does nothing would be a bad thing.  I'm
> kind of hoping you'll just say "as long as you're opening the
> file-system read-only the directory block will be sorted so don't sweat
> it"  Am I dreaming?

So I believe the only place where the dblist.o file is getting dragged
in is due to the call to ext2fs_free_dblist() in freefs.c.  Can you
confirm this?

If so, probably the way to solve this is the via the same trick we do
with fs->write_bitmaps() --- see how we only call fs->write_bitmaps()
if it is defined in ext2fs_close2(); this was done precisely to avoid
dragging in the write_bitmaps code if it's not needed for programs
which are opening the file system read/only.

Regards,

						- Ted
--
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