linux-ext4 - Re: [PATCH 01/37] e2fsprogs: Read and write full-sized inodes

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] [day] [month] [year] [list]

Message-ID: <20110918015216.GF16246@thunk.org>
Date:	Sat, 17 Sep 2011 21:52:16 -0400
From:	Ted Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <djwong@...ibm.com>
Cc:	Andreas Dilger <aedilger@...il.com>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Sunil Mushran <sunil.mushran@...cle.com>,
	Amir Goldstein <amir73il@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Mingming Cao <cmm@...ibm.com>,
	Joel Becker <jlbec@...lplan.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Coly Li <colyli@...il.com>
Subject: Re: [PATCH 01/37] e2fsprogs: Read and write full-sized inodes

On Thu, Sep 15, 2011 at 06:04:30PM -0700, Darrick J. Wong wrote:
> Though I guess I should ask: Is it required that e2fsprogs build on compilers
> that won't do variable-sized stack arrays?  I think that limits us to C99
> compilers that support the feature, but I'm not 100% sure when gcc added that.
> Or if we care about other things like ... Visual Studio? ;)

There are people who have ported libext2fs to Windows, so MSVC
compatibility is something I'd rather not give up.  The other issue
with VLA's is you have to be very careful about buffer overruns, for
the obvious reasons.

At least for e2fsprogs, we don't have to worried about locking, so at
least for read verification, in the case of reading the base 128 byte
inode it would be possible to just verify the whole inode while it is
in the disk buffer.  And on the write side, since we need to do the
read/modify/write cycle, at least in the normal case it's not clear to
me that we need to use dynamic allocation in as many places as we
might think, if we're a bit clever about things.

Even if we need to save and restore the checksum fields in the disk
buffer, and zero them out while we do the checksum, it's still faster
than needing to copy the whole inode, even if we avoid doing the
malloc by using VLA....

There will be a few cases where we need to malloc and grab the whole
inode (debugfs has one case already), but in most cases I suspect it
can be avoided.

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