linux-ext4 - Re: [PATCH 0/6] RFC: (partially) endian-annotate 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: <628B9FD2-9EF0-4849-84E0-D30C0B84CEFA@dilger.ca>
Date:	Thu, 23 Oct 2014 17:56:30 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 0/6] RFC: (partially) endian-annotate e2fsprogs

On Oct 23, 2014, at 3:26 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> This is really only partial, and in the end didn't spot any
> actual problems.  And things are a bit odd and tricky, because
> some structures (superblocks, inodes, etc) are swapped in-place
> in the same structure (so they can't be easily annotated - 
> if we wish to, we should define separate on-disk and in-memory
> structures).

Yeah, and this was a source of bugs in the past...  I wonder if
it would make sense to declare a different inode struct for use
in case EXT4_EXTENTS_FL is set so that it can declare i_block
in terms of extent structures?  Sadly, I recall that ext3_extent
and ext3_extent_idx do not have their fields aligned in the same
way, which makes swabbing sad...

> Further, i_block in the inode is sometimes swapped on read, and
> sometimes not (!), depending on whether it's indirect blocks,
> extents, or inline data.  So that's still messy too.
> 
> So this is really just kind of an RFC; I did it on a whim, and
> things aren't yet totally sparse-check clean, but figured I'd send
> it out and see what people think, whether it's worth merging,
> or working on cleaning up the above issues to make it all tidier.

I definitely think this is worthwhile.  I'd guess most people
contributing to e2fsprogs are already used to this from the kernel,
so it won't slow them down, and we almost certainly don't get
enough big-endian testing and this is at least a good way to catch
likely problems.

> (sparse is pretty good at looking for casts in and out of blk64_t
> too, though I haven't looked much at those.)
> 
> Thanks,
> -Eric
> --
> 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


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)