linux-ext4 - Re: Updated ext4 quota design document

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:	Tue, 22 Jun 2010 22:29:27 +0200
From:	Jan Kara <jack@...e.cz>
To:	tytso@....edu
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: Updated ext4 quota design document

On Tue 22-06-10 16:08:53, tytso@....edu wrote:
> On Tue, Jun 22, 2010 at 04:20:47PM +0200, Jan Kara wrote:
> >   It might be reasonable to checksum dquots so that we get closer to
> > all-metadata-are-checksummed state. I'm just thinking whether checksumming
> > each dquot is so useful. For example OCFS2 checksums each quota block. That
> > has an advantage that also quota file tree blocks and headers are
> > protected. Also it's possible to use the generic block checksumming
> > framework in JBD2 for this case. OTOH ext4 seems to have chosen to checksum
> > each group descriptor individually so checksumming each dquot structure
> > would seem more consistent.
> 
> Well, the reason why I suggested just checksuming the each quota entry
> is that it was the simplest thing to do, and wouldn't require making
> huge changes to the rest of the quota_tree code.  It also means we
> don't need to do any kind of special locking to make sure there isn't
> another process modifying another quota entry in the same block at the
> same time that we are calculating the per-block checksum --- i.e.,
> some of the headaches that we're seeing with the DIF code.
  With metadata which get journaled it should be quite easy. JBD already
must know before you go and modify buffer contents - that's why
journal_get_write_access and friends exist. It also makes sure that your
data cannot be modified from the moment the buffer enters commit upto the
moment the commit is finished. So you can use buffer commit hook to compute
and store block checksum safely.

> >   So I don't have a strong opinion which checksumming scheme should be
> > chosen. I just wanted to point out that there's another reasonable option.
> > Generic quota code can easily handle both (including leaving some bytes at
> > the end of each block for checksums as it does for OCFS2 now).
> 
> I assume OCFS2 is just using dqdh_pad2 or dqdh_pad1 for its checksum?
  No. quota_tree code sets info->dqi_usable_bs to something smaller than
1 << info->dqi_qtree_depth. Thus quota code leaves a few bytes in each
block unused and ocfs2 stores there the checksum.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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