On Wed, Oct 23, 2019 at 02:27:18AM -0700, Christoph Hellwig wrote: > On Tue, Oct 22, 2019 at 09:30:01AM -0400, Theodore Y. Ts'o wrote: > > If and when we actually get inline crypto support for server-class > > systems, hopefully they will support 128-bit DUN's, and/or they will > > have sufficiently fast key load times such that we can use per-file > > keying. > > NVMe is working on a key per I/O feature. So at very least the naming > of this option should be "crappy_underwhelming_embedded_inline_crypto" If and when the vaporware shows up in real hardware, and assuming that fscrypt is useful for this hardware, we can name it "super_duper_fancy_inline_crypto". :-) Remember that fscrypt only encrypts the data and the file name. It doesn't encrypt the metadata. It has very specific use cases for Android and ChromeOS where you have multiple users that need to use different keys, and in the case of ChromeOS, we want to be able to efficiently use the space so that while user A is logged in, we can delete files in user B's cache directory without user B's keys being present. (This is why we can't use fixed per-user partitions with dm-crypt; that solution was considered and rejected before we started work on fscrypt.) If you aren't working under tight space and cost constraints, it's actually better to encrypt the whole partition, so that all of the metadata can be protected. fscrypt is deployed in millions and millions of devices, and is solving real world problems. However, it never claimed to be the only way to address encryption in the storage stack --- and it's not at all clear fscrypt is the way that makes the most amount of sense for NVMe devices. So let's cross that bridge when we get to it. Cheers, - Ted
