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 2BF58C433FE for ; Mon, 15 Nov 2021 19:05:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D0E8F636D7 for ; Mon, 15 Nov 2021 19:05:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D0E8F636D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7404B6B007D; Mon, 15 Nov 2021 14:05:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C9BB6B007E; Mon, 15 Nov 2021 14:05:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5918A6B0080; Mon, 15 Nov 2021 14:05:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 47DFD6B007D for ; Mon, 15 Nov 2021 14:05:04 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F1AFD83E93 for ; Mon, 15 Nov 2021 19:05:03 +0000 (UTC) X-FDA: 78812092086.11.C8AD1AB Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf25.hostedemail.com (Postfix) with ESMTP id 097B4B0001AA for ; Mon, 15 Nov 2021 19:04:49 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1D4FF636D2; Mon, 15 Nov 2021 19:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1637003102; bh=OxbA2Dy+guUtV/oxu3huaKUI54o5bkpBbR72qWRaAfQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FxEl08qu4dUEMgEsJFpcX25p/KAprHCVG4O2xUjklk6MvshRaaVwAbSWxfPyA3ba3 G5+kXBoJGUkezo7WNhBgi7qQVqg29NVjmQ/iemHcndYQvpHT/o2OusJ6ufzGCTt+X3 COwh9q9xxmf2+gdOCzIjNRJdYEmTDEEmGYON1C6E7fpxnhNw1Y4p/lUjcPsdYh267J C3X3PW3x+ePAkJZQrUJ7enxU3FrOy4YKGrdwtzow9e996b4sFxvokIygVh8H3+jh5G +nw98sTQbGfTlWDj+RTeADtMTm/qxJwgZO1jIRN9zBcTRtzn63a8XeyX6Ju7SZR0oI WB07kdDfXRzhA== Date: Mon, 15 Nov 2021 11:05:00 -0800 From: Eric Biggers To: Roberto Sassu 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 Message-ID: References: <20211112124411.1948809-1-roberto.sassu@huawei.com> <20211112124411.1948809-6-roberto.sassu@huawei.com> <6adb6da30b734213942f976745c456f6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6adb6da30b734213942f976745c456f6@huawei.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 097B4B0001AA X-Stat-Signature: cb1zofgxsixuycoxc8da6etf9zuq6g5i Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FxEl08qu; spf=pass (imf25.hostedemail.com: domain of ebiggers@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=ebiggers@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1637003089-951385 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: 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 location > > > 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-relevant > > > operations are checked and handled by fsverity (file open, attr set, inode > > > evict). > > > > > > Fsverity support can be enabled through the kernel configuration and > > > 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 to 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 place. That > > makes sense for a persistent filesystem where a file can be written once 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 whole 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 anyway. > > 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. > It sounds like you really only care about calculating fs-verity file digests. That's just an algorithm for hashing a file, so it could just be implemented 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 special filesystem support to do this. - Eric