Hi David, On Wed, Jan 26, 2022 at 12:44:14PM +0000, David Howells wrote: > Hi, > > I'm looking at doing content encryption in the network filesystem support > library. It occurs to me that if the filesystem can record sparsity in the > file, then a couple of issues may arise if we wish to use that to record > zeroed source blocks (ie. the unencrypted blocks). It further occurs to me > that this may occur in extent-based filesystems such as ext4 that support > fscrypt and also do extent optimisation. > > The issues are: > > (1) Recording source blocks that are all zeroes by not storing them and > leaving a hole in a content is a minor security hole as someone looking > at the file can derive information about the contents from that. This > probably wouldn't affect most files, but it might affect database files. This is working as intended; it's a known trade-off between security and usability that is documented in Documentation/filesystems/fscrypt.rst. eCryptfs worked differently, and that caused lots of problems because things that would be fast on normal filesystems were instead extremely slow. > > (2) If the filesystem stores a hole for a *source* block of zeroes (not an > encrypted block), then it has the same problems as cachefiles: > > (a) A block of zeroes written to disk (ie. an actually encrypted block) > is very, very unlikely to represent a source block of zeroes, but the > optimiser can punch it out to reduce an extent and recover disk space, > thereby leaving a hole. > > (b) The optimiser could also *insert* blocks of zeroes to bridge an > extent, thereby erasing a hole - but the zeroes would be very unlikely to > decrypt back to a source block of zeroes. > > If either event occurs, data corruption will ensue. > > To evade this one, we have to do one of the following: > > 1. Don't use sparsity to record source blocks of zeroes > 2. Disable extent optimisations of these sorts > 3. Keep a separate map of the content > > Now, I don't know if fscrypt does this. It's hard to tell. > Changing an all-zeroes region to a hole (or vice versa) in an encrypted file is impossible without the key, so yes that sort of thing needs to be disabled, e.g. based on whether the inode has the encrypt flag set or not. As far as I know, neither e2fsprogs nor f2fs-tools implement this sort of optimization. e2fsck supports optimizing how the extents are represented on disk, but it doesn't mess with the actual data blocks. - Eric
