Ted, On 22.09.2016 15:14, Theodore Ts'o wrote: > On Thu, Sep 22, 2016 at 10:49:41AM +0200, Richard Weinberger wrote: >> >> While reading the fscrypt code I noticed that some functions use the bounce pages >> and some not. >> fscrypt_decrypt_page() and fscrypt_decrypt_bio_pages() work in-place while >> fscrypt_encrypt_page() and fscrypt_zeroout_range() use a bounce page. >> >> So, both ext4 and f2fs encrypt data using an extra buffer but decrypt mostly >> in-place without the need of an extra buffer. >> Why that? I'd assume when decryption can be done in-place also encryption is possible >> that way. > > The problem is that the page may be mapped into some process's (or > multiple processes') address space. The only way we can encrypt in > place is if we make sure that it is not mapped into any processes' > page tables, and prohibit it from being mmapped, *and* prevent any > simultaneous reads from accessing the page for which we are in the > process of destroying its original contents because we are doing an > in-plance encrypt. > > So it could be done, but you would have to remove the page from the > page cache first (meaning making sure it's not in any page tables) so > it can't be found by subsequent reads and mmaps, and then sure you > have a lock out which prevents anyone else from trying to read or mmap > the page(s) in question, since the version on the storage device is > out-of-date, because it hasn't been written yet. > > So basically, it's a mess, and if you do need the page again after > it's been written, the fact that you have to read it back in from the > storage device would also be a performance hit in some cases. For UBIFS the story is a bit different. UBIFS operates on a kmap()'ed page and has already a temporary buffer where it prepares and compresses data. So, I can use in-place encryption. All I have to do is massaging the fscrypt interface to allow the filesystem to select when a bouncing page (or buffer in my case) is needed or not. I've extended the fscrypt API already to work on buffers too. In MTD world we don't have struct bio and other fancy stuff. :-) Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
