linux-ext4 - Re: fscrypt: in-place decrypt vs. out-of-place encrypt?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 22 Sep 2016 16:13:41 +0200
From:   Richard Weinberger <richard@....at>
To:     Theodore Ts'o <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        David Gstir <david@...ma-star.at>
Subject: Re: fscrypt: in-place decrypt vs. out-of-place encrypt?

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-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html