From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DECCAC433F5 for ; Tue, 16 Nov 2021 15:46:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 31931615E2 for ; Tue, 16 Nov 2021 15:46:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 31931615E2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id AF8B46B007B; Tue, 16 Nov 2021 10:46:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A82FC6B007D; Tue, 16 Nov 2021 10:46:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 949C66B007E; Tue, 16 Nov 2021 10:46:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 840CB6B007B for ; Tue, 16 Nov 2021 10:46:09 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2A0D78249980 for ; Tue, 16 Nov 2021 15:46:09 +0000 (UTC) X-FDA: 78815219616.17.F83B558 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf09.hostedemail.com (Postfix) with ESMTP id ECDA53001417 for ; Tue, 16 Nov 2021 15:31:03 +0000 (UTC) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HtjHN6bskz67mLl; Tue, 16 Nov 2021 18:39:44 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 16 Nov 2021 11:43:27 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.020; Tue, 16 Nov 2021 11:43:27 +0100 From: Roberto Sassu To: Eric Biggers CC: "tytso@mit.edu" , "corbet@lwn.net" , "viro@zeniv.linux.org.uk" , "hughd@google.com" , "akpm@linux-foundation.org" , "linux-fscrypt@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-integrity@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [RFC][PATCH 5/5] shmem: Add fsverity support Thread-Topic: [RFC][PATCH 5/5] shmem: Add fsverity support Thread-Index: AQHX18M/qVU4RXchik23Vn+neZuDEKwAMhaAgAQN/bCAAKcCAIABDzqA Date: Tue, 16 Nov 2021 10:43:27 +0000 Message-ID: <0974034ff3b6426abd89f3c6f45c6d23@huawei.com> References: <20211112124411.1948809-1-roberto.sassu@huawei.com> <20211112124411.1948809-6-roberto.sassu@huawei.com> <6adb6da30b734213942f976745c456f6@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.63.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf09.hostedemail.com: domain of roberto.sassu@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=roberto.sassu@huawei.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: ECDA53001417 X-Stat-Signature: 7jw3ezu4io8sdt7qmqiek89pfny6g41b X-HE-Tag: 1637076663-839508 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > From: Eric Biggers [mailto:ebiggers@kernel.org] > Sent: Monday, November 15, 2021 8:05 PM > On Mon, Nov 15, 2021 at 08:49:41AM +0000, Roberto Sassu wrote: > > > From: Eric Biggers [mailto:ebiggers@kernel.org] > > > Sent: Friday, November 12, 2021 8:12 PM > > > On Fri, Nov 12, 2021 at 01:44:11PM +0100, Roberto Sassu wrote: > > > > Make the necessary modifications to support fsverity in tmpfs. > > > > > > > > First, implement the fsverity operations (in a similar way of f2fs)= . These > > > > operations make use of shmem_read_mapping_page() instead of > > > > read_mapping_page() to handle the case where the page has been > swapped > > > out. > > > > The fsverity descriptor is placed at the end of the file and its lo= cation > > > > is stored in an xattr. > > > > > > > > Second, implement the ioctl operations to enable, measure and read > fsverity > > > > metadata. > > > > > > > > Lastly, add calls to fsverity functions, to ensure that fsverity-re= levant > > > > operations are checked and handled by fsverity (file open, attr set= , inode > > > > evict). > > > > > > > > Fsverity support can be enabled through the kernel configuration an= d > > > > remains enabled by default for every tmpfs filesystem instantiated = (there > > > > should be no overhead, unless fsverity is enabled for a file). > > > > > > > > Signed-off-by: Roberto Sassu > > > > > > I don't see how this makes sense at all. The point of fs-verity is t= o avoid > > > having to hash the whole file when verifying it. However, obviously = the > whole > > > file still has to be hashed to build the Merkle tree in the first pla= ce. That > > > makes sense for a persistent filesystem where a file can be written o= nce and > > > verified many times. I don't see how it makes sense for tmpfs, where= files > have > > > to be re-created on every boot. You might as well just hash the whol= e file. > > > > The point of adding fsverity support for tmpfs was to being able to do > > integrity enforcement with just one mechanism, given that I was > > planning to do integrity verification with reference values loaded > > to the kernel with DIGLIM [1]. > > > > With an LSM such as IPE [2], integrity verification would consist in > > querying the fsverity digest with DIGLIM and allowing the operation > > if the digest was found. With fsverity support in tmpfs, this can be > > done from the very beginning of the boot process. > > > > Using regular file digests would be also possible but this requires > > loading with DIGLIM both fsverity and non-fsverity reference values. > > It would also require two separate mechanisms for calculating > > the file digest depending on the filesystem. It could be done, but > > I thought it was easier to add support for fsverity in tmpfs. > > > > > Also, you didn't implement actually verifying the data (by calling > > > fsverity_verify_page()), so this patch doesn't really do anything any= way. > > > > Yes, at the end I didn't add it. Probably the only place where > > calling fsverity_verify_page() would make sense is when a page > > is swapped in (assuming that the swap device is untrusted). > > > > I tried to add a call in shmem_swapin_page() but fsverity complained > > due to the fact that the page was already up to date, and also > > rejected the page. I will check it better. > > >=20 > It sounds like you really only care about calculating fs-verity file dige= sts. > That's just an algorithm for hashing a file, so it could just be implemen= ted in > generic code that operates on any file on any filesystem, like how IMA > implemennts full file hashing for any file. There isn't a need for any s= pecial > filesystem support to do this. Initially I thought the same. Then, I realized that fsverity is much more than that. Fsverity could be seen as a sort of property enforcer, it provid= es a property associated to the file (the fsverity digest) and ensures that the property remains the same while the system is running. In addition, it takes advantage of the page cache to avoid remeasuring an up to date page. This remove some burden from LSMs. IPE would have just to compare the fsverity digest with that in the policy (or just query it with DIGLIM). Not taking into consideration the specific filesystem, not having to fall back to the new fsverity measurement function, and avoiding to preserve the fsverity property by itself, would make the LSM implementation very simple. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua