Hi Dave, On Thu, Aug 08, 2019 at 06:16:47PM +1000, Dave Chinner wrote: > On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote: > > FWIW, the only order that actually makes sense is decrypt->decompress->verity. > > *nod* > > Especially once we get the inline encryption support for fscrypt so > the storage layer can offload the encrypt/decrypt to hardware via > the bio containing plaintext. That pretty much forces fscrypt to be > the lowest layer of the filesystem transformation stack. This > hardware offload capability also places lots of limits on what you > can do with block-based verity layers below the filesystem. e.g. > using dm-verity when you don't know if there's hardware encryption > below or software encryption on top becomes problematic... > > So really, from a filesystem and iomap perspective, What Eric says > is the right - it's the only order that makes sense... Don't be surprised there will be a decrypt/verity/decompress all-in-one hardware approach for such stuff. 30% random IO (no matter hardware or software approach) can be saved that is greatly helpful for user experience on embedded devices with too limited source. and I really got a SHA256 CPU hardware bug years ago. I don't want to talk more on tendency, it depends on real scenerio and user selection (server or embedded device). For security consideration, these approaches are all the same level --- these approaches all from the same signed key and storage source, all transformation A->B->C or A->C->B are equal. For bug-free, we can fuzzer compression/verity algorithms even the whole file-system stack. There is another case other than security consideration. Thanks, Gao Xiang > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
