linux-kernel - Re: [PATCH] fs: Introducing Lanyard Filesystem

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]

Date:	Sun, 19 Aug 2012 16:12:51 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dan Luedtke <mail@...rl.de>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: Introducing Lanyard Filesystem

On Sun, Aug 19, 2012 at 06:53:37PM +0200, Dan Luedtke wrote:
> > 	* minor point, but endianness-flipping in place is *the* way to get
> > hard-to-catch endianness bugs.  foo = cpu_to_le64(foo) is a bloody bad idea;
> > either use object for host-endian all along, or use it only for (in your
> > case) little-endian.
> I am not sure I understood this right.
> At what point should I convert e.g. the file size (little endian 64bit
> value stored on disk) to host endianess? When filling the inode?
> Is inode->i_size = le64_to_cpu(size) bad, too?

Conversions *in* *place* are bad.  The above is fine if you have 'size'
variable used only for little-endian values (and declare it __le64, then).
The thing is, thinking of endianness conversions as architecture-conditional
byteswaps is wrong.  Treat them as you would treat dealing with some
encoding; that's the reason why we have separate le64_to_cpu() and
cpu_to_le64(), even though they are identical as functions - on all
architectures we support.  And don't use the same variable for both the
host- and fixed-endian values; it's far too easy to get confused on
code modifications and get the situation when two code paths lead to
the same point, one with host-endian value in that variable and another
with fixed-endian.  Real fun to debug, especially when one of the codepaths
is rarely taken...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/