linux-ext4 - Re: [RFC PATCH 02/10] fs-verity: add data verification hooks for ->readpages()

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <c907ad1d-c7c8-714a-0e59-373c1df3afe8@huawei.com>
Date:   Sat, 25 Aug 2018 15:43:43 +0800
From:   Gao Xiang <gaoxiang25@...wei.com>
To:     Eric Biggers <ebiggers@...nel.org>
CC:     <linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>,
        <linux-f2fs-devel@...ts.sourceforge.net>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Michael Halcrow <mhalcrow@...gle.com>,
        <linux-kernel@...r.kernel.org>, <linux-fscrypt@...r.kernel.org>,
        <linux-integrity@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Victor Hsieh <victorhsieh@...gle.com>
Subject: Re: [RFC PATCH 02/10] fs-verity: add data verification hooks for
 ->readpages()

Hi Eric,

On 2018/8/25 15:18, Eric Biggers wrote:
> We do have to be very careful here, but the same restriction already exists with
> fscrypt which both f2fs and ext4 already support too.  With fscrypt, each page
> is decrypted with the key from page->mapping->host->i_crypt_info and the
> initialization vector from page->index.  With fs-verity, each page is verified
> using the Merkle tree state from page->mapping->host->i_verify_info and the
> block location from page->index.  So, they are very similar.
> 
> On f2fs, any pages submitted via META_MAPPING just skip both fscrypt and
> fs-verity since the "meta_inode" doesn't have either feature enabled.  That's
> done intentionally, so that garbage collection can move the blocks on-disk.
> Regular reads aren't done via META_MAPPING.
> 

I think you deal with the existed cases quite well, I was just thinking about EROFS... :)

> I don't know of any plan to use fs-verity on Android's system partition or to
> replace dm-verity on the system partition.  The use cases so far have been
> verifying files on /data, like APK files.
> 
> So I don't think you need to support fs-verity in EROFS.
> 

Thanks for your information about fs-verity, that is quite useful for us
Actually, I was worrying about that these months...  :)

> Re: the compression, I don't see how it would be much of a problem (even if you
> did need or want to add fs-verity support).  Assuming that the verification is
> done over the uncompressed version of the data, you wouldn't verify the pages
> directly from the bio's page list since those would contain compressed data.
> But even without fs-verity you'd need to decompress the data into pagecache
> pages... so you could just call fsverity_verify_page() on each of those
> decompressed pages before unlocking them and setting them Uptodate.  You don't
> *have* to call fsverity_verify_bio() to do the verification; it's just a helper
> for the case where the list of pages to verify happens to be in a completed bio.
> 

I haven't look into all patches, I will look into that carefully if I finish my current job.
It is wonderful to have such a helper --- fsverity_verify_page :)

I have no other problem currently, and look forward for your final implementation.

Best Regards,
Gao Xiang

> - Eric