linux-kernel - Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature

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:	Sat, 16 May 2015 10:13:26 -0700
From:	Tom Marshall <tom@...gn.com>
To:	Theodore Ts'o <tytso@....edu>, Dave Chinner <david@...morbit.com>,
	Jaegeuk Kim <jaegeuk@...nel.org>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs
 encryption feature

On Sat, May 16, 2015 at 09:24:03AM -0400, Theodore Ts'o wrote:
> [...] What's going to be more difficult in the long run is
> when we want to support per-block data integrity, using (for example)
> AES/GCM, which will require 32 bytes of per-block "authentication tag"
> (think Message Authentication Code) that have to be committed
> atomically with the data block write.
> 
> Quite frankly, this is going to be much easier for COW file systems
> like f2fs and btrfs.  I have some ideas about how to do this for
> update-in-place file systems (using either a compression hack and/or
> storing two generations worth of authentication tag per block), but
> it's not pretty.  (Or in the case of ext4 we could use
> data=journalling mode, but that's even less pretty from a performance
> standpoint.)

It seems to me that compression has a similar issue with framing metadata. 
The block map can be stored upfront, which then would require two writes to
update a data block.  Or it can be stored inline, which then would require
scanning through the file sequentially for random access.

The big difference, of course, is that in the case of compression, we have
the luxury of assuming or mandating read-only/read-mostly.
--
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/