Down the road, I do think we'll be able to implement authenticated encryption more easily than a dm layer mechanism will, because we've got existing transactional facilities to give us consistency between the crypto metadata and the ciphertext, and we expect to get per-block metadata support from Mingming when it's ready. I've got a roadmap for that, but we're taking this one step at a time and doing unauthenticated crypto first.

Once we start talking about managing additional per-block metadata with transactional semantics, we're pretty far into "file system" territory. With that extra data, we'll need to make some decisions around I/O patterns, memory usage, and so forth. The file system is the best place to manage that sort of complexity.

If you've got a single-user laptop that's subject to being left in a taxi, FDE like dm-crypt makes a lot of sense.

If it's more complicated than the single-user laptop story, you often need to jump through hoops to make it work with FDE. Pushing a key into the keyring and setting a policy on a directory for an existing file system vastly simplifies many scenarios. Multi-user environments such as Android, Chrome OS, and Cloud servers are targets for encryption that can be selectively enabled and managed on shared live mounted file systems with multiple users.

Now that’s… puzzling.

They have different use cases of course: a per-file nonce instead of a per-block nonce, and differing keys, which is kinda neat, but I’d actually expect dmcrypt to perform *better*.

Sigh. I should have pointed out that I meant hard links. Symlinks are not interesting.

>> What happens when a file is moved into or out of the encrypted directory?

> It is rewritten according to the crypto policy on the destination.

Ok, so what happens if I make a link to an encrypted file so that there exists a (hard) link to it both inside the encrypted directory and outside of it? Or if I make a (hard) link to a non-encrypted file that appears below the encrypted directory?

> I don't see any departure from how file system structures have worked in the past.

Well, in the "good old days" files in a file system were not arranged hierarchically, but existed as a flat collection where each file was referenced by inode number. On top of that we had directories mapping names to inodes. In the really good old days a directory was not much more than a file containing records each containing an inode number and a string giving the name of the file.

The same file could have several names in the same directory or any other directories within the same file system. The file object itself had no knowledge of under which name and from which directories it was referenced from. In fact, a file might not have a name at all but still exist. As long as the file is open for a process, you can delete it from all directories and still read or write to it.

Based on the prevalent usage patterns I've been seeing for eCryptfs, which lets you specify one policy per mount point, this per-top-level-directory approach to policy will work fine. My initial prototype let you specify file-granular policies with fancy things like synthesizing multiple keys, but it took too much xattr space and didn't seem to address any compelling requirements.

We've talked about in the future adding public key crypto, in which case there will be a per-inode key that would get encrypted once so that Alice's private key will be able to obtain the per-inode key, and once so that Bob's private key could obtain the per-inode key.

In the initial prototype, we had this support w/o public key crypto, and it didn't add a lot of value, since it meant that at the time when you created the file, you would need to have Alice and Bob's symmetric key in memory, and for both Android and Chrome OS, an important design principle is that if a user is not logged in, their key is not available (at least not in decrypted form) anywhere on the system.

The other problem is that in the initial prototype, even when you had a single per-inode key wrapped with a single user's symmetric key, the resulting size of the extended attribute, combined with the size of the SELinux policy xattr (which is a _pig_; it uses a very verbose ascii string), the resulting xattrs would require an external 4k block for each inode. This was considered extremely unfortunate.

So hence we decided to fall back to using a very compact encoding for files that were encrypted for only a single user. In the future we'll add a version 2 on-disk structure which will allow for a file to use a per-file key encrypted by multiple users' public keys. Public key is also a pig, so at that point you will definitely need to go to an external xattr block --- but the assumption is that the number of shared files that would need to be accessible by multiple users will be relatively small. Or maybe we could do something by adding another layer of indirection. We'll see. The bottom line is that there's a pretty tight deadline for getting kernel changes in for the 'M' release, and what we have is sufficient for the use cases articulated to us by both the ChromeOS and Android teams.

What might get supported in releases beyond that will be a different question, but we have plenty of time to figure that out. Consider this the first step in a journey, not the end point.

[1] "My God, it's full of s..."

Ouch, yes, the difference is huge. At one point we had a server which was going dog-slow, while an apparently identical server next to it had no problems. After much searching it turned out that for some reason on this server the aesni_intel module was not getting loaded. An extra line in /etc/modules and a reboot later everything back to normal.

If the goal of this patch it to make as much of the filesystem usable without invoking any encryption then it explains some of the choices, but it's definitely a feature aimed at embedded processors.