linux-kernel - Re: [PATCH 0/2] Add inode checksum support to ext4

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: <20110728220735.GA27253@noexit.corp.google.com>
Date:	Thu, 28 Jul 2011 15:07:36 -0700
From:	Joel Becker <jlbec@...lplan.org>
To:	"Darrick J. Wong" <djwong@...ibm.com>
Cc:	Andreas Dilger <aedilger@...il.com>, Mingming Cao <cmm@...ibm.com>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Add inode checksum support to ext4

On Thu, Jul 28, 2011 at 09:56:15AM -0700, Darrick J. Wong wrote:
> > the block. There of course is no reason to put an extent tail inside the
> > inode itself.
> 
> Does anybody have any objection to using crc32c (which we can hardware
> accelerate on new Intel boxen) over crc16?  I think it'll be pretty easy to use

	We use ethernet crc32 in ocfs2.  btrfs uses crc32c.  Frankly, I
could have used crc32c if I'd really thought about the hardware
acceleration benefits.  I think it's a good idea for ext4.

> some of the reserved space in the group descriptor to store checksums of the
> block and inode bitmaps.  Adding tails to the extent tree blocks seems a bit
> trickier than that, but not a big deal, though I guess I'll have to reshuffle
> the extent tree to free up space at the end of the block.
> 
> I was also wondering what people think of adding checksums to directory files?
> I think that it's possible to put a checksum in each directory block -- for
> blocks containing a linear array of actual directory entries, we could zero out
> the space past the end of the array and put a checksum at the very end of the
> block.  For the dx_node/dx_root blocks, we could probably use the space
> occupied by the last dx_entry to store the checksum.  Obviously, we'd have to
> move whatever's at the end of the block elsewhere, but then, we have to do that
> for the extent tree too.  Basically, the last 4 bytes become the checksum after
> whatever's occupying the space is relocated. :)

	ocfs2 adds trailer entries to every dirblock for the checksum.
We also do our dirindex free list there.  Since ocfs2 dirblocks are ext3
dirblocks, I bet you can rip off a lot of that code, including the
feature compatibility stuff.  See ocfs2_fs.h.

> It looks like there's sufficient unused space in ext4_xattr_header to add a
> checksum.
> 
> Also -- should I create separate rocompat feature flags for each metadata
> object that I add checksums to?  Or just have one flag that covers them all?

	I really think you should checksum every metadata block.  A few
things will take some effort to shoehorn it in, but it is worth it.

Joel

-- 

Life's Little Instruction Book #173

	"Be kinder than necessary."

			http://www.jlbec.org/
			jlbec@...lplan.org
--
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/