On Fri, May 31, 2024 at 02:28:50PM -0700, Darrick J. Wong wrote: > On Wed, May 22, 2024 at 11:29:00AM -0700, Eric Biggers wrote: > > On Wed, May 22, 2024 at 07:37:23AM -0700, Christoph Hellwig wrote: > > > On Mon, May 20, 2024 at 09:02:59AM -0700, Darrick J. Wong wrote: > > > > On Mon, May 20, 2024 at 05:39:59AM -0700, Christoph Hellwig wrote: > > > > > On Fri, May 17, 2024 at 10:17:20AM -0700, Darrick J. Wong wrote: > > > > > > > Note that the verity metadata *must* be encrypted when the file is, > > > > > > > since it contains hashes of the plaintext data. > > > > > > > > > > > > Refresh my memory of fscrypt -- does it encrypt directory names, xattr > > > > > > names, and xattr values too? Or does it only do that to file data? > > > > > > > > > > It does encrypt the file names in the directories, but nothing in > > > > > xattrs as far as I can tell. > > > > > > > > Do we want that for user.* attrs? That seems like quite an omission. > > > > > > I'll let Eric answer that. Btw, is the threat model for fscrypt written > > > down somewhere? > > > > See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html?highlight=fscrypt#threat-model > > > > As for why it stopped at file contents and names (and fsverity Merkle tree > > blocks which ext4 and f2fs encrypt in the same way as contents), it's just > > because it's very difficult to add more, and file contents and names alone were > > enough for parity with most other file-level encryption systems. That's just > > the nature of file-level encryption. For each additional type of data or > > metadata that's encrypted, there are a huge number of things that need to be > > resolved including algorithm selection, key derivation, IV selection, on-disk > > format, padding, UAPI for enabling the feature, userspace tool support including > > fsck and debugging tools, access semantics without the key, etc... > > > > xattr encryption is definitely something that people have thought about, and it > > probably would be the next thing to consider after the existing contents and > > names. Encrypting the exact file sizes is also something to consider. But it's > > not something that someone has volunteered to do all the work for (yet). If you > > restricted it to the contents of user xattrs only (not other xattrs, and not > > xattr names), it would be more feasible than trying to encrypt the names and > > values of all xattrs, though it would still be difficult. > > > > Of course, generally speaking, when adding fscrypt support to a filesystem, it's > > going to be much easier to just target the existing feature set, and not try to > > include new, unproven features too. (FWIW, this also applies to fsverity.) If > > someone is interested in taking on an experimental project add xattr encryption > > support, I'd be glad to try to provide guidance, but it probably should be > > separated out from adding fscrypt support in the first place. > > Does the fscrypt data unit size have to match i_blocksize? Or the > fsverity merkle tree block size? The crypto data unit size is a power of 2 less than or equal to i_blocksize (usually equal to it, as that is the default). See https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#contents-encryption It applies to contents encryption only, though as you know, ext4 and f2fs treat the Merkle tree in mostly the same way as contents, including for encryption. For an implementation of fsverity that doesn't treat the Merkle tree as contents like this, and where the filesystem supports fscrypt too, encryption of the Merkle tree would need to be implemented a bit differently. It wouldn't need to use the same crypto data unit size as the contents, e.g. it could be always one data unit per Merkle tree block. - Eric
