Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3507132imm; Fri, 24 Aug 2018 19:32:18 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ08pTEVc2TjpH6MB5+tuNl2YF4EXr4J/Rxd+6SuVXuT3vQUDpW8wW8W2MPQa2RAWVrNfVx X-Received: by 2002:a17:902:d808:: with SMTP id a8-v6mr3982343plz.68.1535164338265; Fri, 24 Aug 2018 19:32:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535164338; cv=none; d=google.com; s=arc-20160816; b=AugaPtjA4AUOefnYpbBkEmZjylMapKnqCnDxMGUuzH1uZPG+/dvqp9Uw/eqLvpglvo tUor0XJMTjPFLf5Dgux5WcMg/0/o7cI8FwtPX93J7nk5H/YZvdtnrQwMbM4DK57EmRYx rOiZMEBVZrIeubJuIP4amhRGhXtI3EkEMmx9kzECsAH5M3IYFPy5XoqhLG6nMyqEk6Fq r81+n9rpY1CVoQId2VAYNm4U3JAbNLzfvaVHOhUUmRJ5AHbguTfo0wvDidAb0kUWYtLJ 4X7g307PmJO0bb4GBzfyQ8j5tumG0jOIIgJHDS1LbS2o+Q/o5/gJi5eRx6tCbJXYhTb+ ptbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject:arc-authentication-results; bh=KCW+kASjivUvFNtMCg8IfyPqSz7yAsTh1igbbZoWtT4=; b=gtDYJXne3X4G6A9LaAFy32NC6mNFAEFzgIYIlJ9ShOMY5e7jw4W83v/RpJLwZnkJ2L a9OQiev1sI6A5yd6/yn8nkk+gpjJHCwOCxPOSkW0jcvRHgFbV0f3PTzKWtEvNAW5g/qz HJ+/l15EZgEMMJu48vWp4943g/Z+qto/qL7ejqqj31vr4dc/vyJguD9Eu3joJJ/2oqrj VgbmmnJ0lXTrNgPFl4FY17sMcFUGvLE9WUsti7vJD3W6AhRDEmm+aQSOh7Kh3tdlDv0w v8/8Tv4XhHe7Gh2gaNHqEzAMR8E3wArXPyYrj1F6DNdyqoqLE0wqsUJuf8Q8ty4VSeN+ tjVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7-v6si7693499pgp.551.2018.08.24.19.32.02; Fri, 24 Aug 2018 19:32:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727079AbeHYGIN (ORCPT + 99 others); Sat, 25 Aug 2018 02:08:13 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:11195 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726138AbeHYGIM (ORCPT ); Sat, 25 Aug 2018 02:08:12 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 9A7667B24E499; Sat, 25 Aug 2018 10:30:53 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 25 Aug 2018 10:30:50 +0800 Subject: Re: [f2fs-dev] [RFC PATCH 02/10] fs-verity: add data verification hooks for ->readpages() To: Eric Biggers , , , CC: Dmitry Kasatkin , Michael Halcrow , , , , "Mimi Zohar" , Victor Hsieh References: <20180824161642.1144-1-ebiggers@kernel.org> <20180824161642.1144-3-ebiggers@kernel.org> From: Gao Xiang Message-ID: <2f2382c3-e5e9-f0da-dc89-42dfc7b2b636@huawei.com> Date: Sat, 25 Aug 2018 10:29:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20180824161642.1144-3-ebiggers@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.151.23.176] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2018/8/25 0:16, Eric Biggers wrote: > +/** > + * fsverity_verify_page - verify a data page > + * > + * Verify a page that has just been read from a file against that file's Merkle > + * tree. The page is assumed to be a pagecache page. > + * > + * Return: true if the page is valid, else false. > + */ > +bool fsverity_verify_page(struct page *data_page) > +{ > + struct inode *inode = data_page->mapping->host; > + const struct fsverity_info *vi = get_fsverity_info(inode); > + struct ahash_request *req; > + bool valid; > + > + req = ahash_request_alloc(vi->hash_alg->tfm, GFP_KERNEL); > + if (unlikely(!req)) > + return false; > + > + valid = verify_page(inode, vi, req, data_page); > + > + ahash_request_free(req); > + > + return valid; > +} > +EXPORT_SYMBOL_GPL(fsverity_verify_page); > + > +/** > + * fsverity_verify_bio - verify a 'read' bio that has just completed > + * > + * Verify a set of pages that have just been read from a file against that > + * file's Merkle tree. The pages are assumed to be pagecache pages. Pages that > + * fail verification are set to the Error state. Verification is skipped for > + * pages already in the Error state, e.g. due to fscrypt decryption failure. > + */ > +void fsverity_verify_bio(struct bio *bio) > +{ > + struct inode *inode = bio_first_page_all(bio)->mapping->host; > + const struct fsverity_info *vi = get_fsverity_info(inode); > + struct ahash_request *req; > + struct bio_vec *bv; > + int i; > + > + req = ahash_request_alloc(vi->hash_alg->tfm, GFP_KERNEL); > + if (unlikely(!req)) { > + bio_for_each_segment_all(bv, bio, i) > + SetPageError(bv->bv_page); > + return; > + } > + > + bio_for_each_segment_all(bv, bio, i) { > + struct page *page = bv->bv_page; > + > + if (!PageError(page) && !verify_page(inode, vi, req, page)) > + SetPageError(page); > + } > + > + ahash_request_free(req); > +} > +EXPORT_SYMBOL_GPL(fsverity_verify_bio); Out of curiosity, I quickly scanned the fs-verity source code and some minor question out there.... If something is wrong, please point out, thanks in advance... My first question is that 'Is there any way to skip to verify pages in a bio?' I am thinking about If metadata and data page are mixed in a filesystem of such kind, they could submit together in a bio, but metadata could be unsuitable for such kind of verification. The second question is related to the first question --- 'Is there any way to verify a partial page?' Take scalability into consideration, some files could be totally inlined or partially inlined in metadata. Is there any way to deal with them in per-file approach? at least --- support for the interface? At last, I hope filesystems could select the on-disk position of hash tree and 'struct fsverity_descriptor' rather than fixed in the end of verity files...I think if fs-verity preparing such support and interfaces could be better.....hmmm... :( Thanks, Gao Xiang