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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 27 Jun 2012 21:21:17 +1000
From:	Tony Breeds <tony@...eyournoodle.com>
To:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: Minimal configuration for e2fsprogs

On Fri, Jun 15, 2012 at 02:24:21PM +1000, Tony Breeds wrote:
> Hi All,
> 	I appologise if this is not the correct place to discuss this,
> or if it's been discussed before.  In either event please point me in
> the right direction and I'll move along.
> 
> I'm the maintainer for yaboot a bootloader for powerpc systems.  We link
> against libext2fs.a, but as we're a bootloader we do NOT link against
> libc as such we need to implement a number of "stub" functions to keep
> up with the newer features being added here.

Okay working with an e2fsprogs that has the various patches I've posted
to this list in the last few days I'm down to:
---
/home/tony/src/e2fsprogs/../e2fsprogs-root/lib/libext2fs.a(inline.o): In function `ext2fs_get_arrayzero':
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/ext2fs.h:1521: undefined reference to `calloc'
/home/tony/src/e2fsprogs/../e2fsprogs-root/lib/libext2fs.a(blkmap64_rb.o): In function `rb_get_new_extent':
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/blkmap64_rb.c:138: undefined reference to `perror'
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/blkmap64_rb.c:139: undefined reference to `exit'
/home/tony/src/e2fsprogs/../e2fsprogs-root/lib/libext2fs.a(dblist.o): In function `ext2fs_dblist_sort2':
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/dblist.c:217: undefined reference to `qsort'
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/dblist.c:217: undefined reference to `qsort'
/home/tony/src/e2fsprogs/../e2fsprogs-root/lib/libext2fs.a(dblist.o): In function `ext2fs_dblist_sort':
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/dblist.c:322: undefined reference to `qsort'
/home/tony/src/e2fsprogs-build/lib/ext2fs/../../../e2fsprogs/lib/ext2fs/dblist.c:322: undefined reference to `qsort'
---
As I've said adding calloc to yaboot is quite reasonable so we can
ignore this one.

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.

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?

As always happy to do what I can if pointed in the right direction.

Yours Tony

Content of type "application/pgp-signature" skipped