From patchwork Fri Nov 12 12:44:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roberto Sassu X-Patchwork-Id: 12616737 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 842C9C433F5 for ; Fri, 12 Nov 2021 12:44:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2B6361039 for ; Fri, 12 Nov 2021 12:44:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F2B6361039 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 3870D6B0074; Fri, 12 Nov 2021 07:44:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 336516B0078; Fri, 12 Nov 2021 07:44:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 224996B007B; Fri, 12 Nov 2021 07:44:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 0FBA86B0074 for ; Fri, 12 Nov 2021 07:44:44 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C062279A66 for ; Fri, 12 Nov 2021 12:44:43 +0000 (UTC) X-FDA: 78800247246.24.0B063CF Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf01.hostedemail.com (Postfix) with ESMTP id 195ED509265B for ; Fri, 12 Nov 2021 12:44:27 +0000 (UTC) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HrJ7j1z46z67bYH; Fri, 12 Nov 2021 20:39:45 +0800 (CST) Received: from roberto-ThinkStation-P620.huawei.com (10.204.63.22) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 12 Nov 2021 13:44:39 +0100 From: Roberto Sassu To: , , , , , CC: , , , , , , Roberto Sassu Subject: [RFC][PATCH 0/5] shmem/fsverity: Prepare for mandatory integrity enforcement Date: Fri, 12 Nov 2021 13:44:06 +0100 Message-ID: <20211112124411.1948809-1-roberto.sassu@huawei.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-Originating-IP: [10.204.63.22] X-ClientProxiedBy: lhreml753-chm.china.huawei.com (10.201.108.203) To fraeml714-chm.china.huawei.com (10.206.15.33) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 195ED509265B X-Stat-Signature: 766sr4yhpr5wtzheax79y8i6ymgnnmak Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of roberto.sassu@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=roberto.sassu@huawei.com X-HE-Tag: 1636721067-760767 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: The biggest advantage of fsverity compared to file-based solutions like IMA is the lower overhead added for integrity measurement and enforcement. Although fsverity offers the same file representation as a digest, it works instead at page granularity rather than file granularity. Only the pages that are going to be used will be evaluated by fsverity, while IMA has to read the whole file. Although fsverity has a built-in enforcement mechanism, it is basically discretionary, it can be enabled (or disabled by replacing the file) by the user himself. A mandatory mechanism could be used to impose fsverity protection for files involved in certain events, defined with a policy. Integrity Policy Enforcement (IPE) is one of such mandatory mechanisms designed to work in conjunction with fsverity (IMA integration is planned). However, at this stage (v7), IPE is storing fsverity data at file instantiation time rather than at usage time. One disadvantage of such approach is that a security blob needs to be allocated and maintained for such purpose, which makes the code unnecessarily more complex. A much better approach would be to retrieve the information when needed, without storing it in a security blob. Another gap that currently limits the applicability of fsverity is the missing support for the tmpfs filesystem. Files could still be executed from it (e.g. during the boot process) and would still need to be verified by IPE. Not verifying those files would considerably reduce the effectiveness of the integrity protection. Alternatively, requiring that the initial ram disk is signed limits the applicability of the solution only to embedded systems, where the initial ram disk can be also distributed. General purpose OSes instead regenerate it locally depending on the system configuration, and after critical packages changes. Given that tmpfs is not persistent, the question is if support should be implemented in a similar way of persistent filesystems, such as ext4. And, while fsverity protection needs to be enabled on a file each time a tmpfs filesystem is mounted, probably implementing fsverity support in the same way is simpler. Another question is whether and when pages should be checked. In a preliminary test, checking a page after it was swapped in resulted in the page not being considered valid by fsverity. For now there are no calls to fsverity_verify_page(). The implementation in this patch set is not necessarily the most efficient, and does not consider the specific features of tmpfs. The goal was to aim at correctness, by following closely the implementation for f2fs, doing the minimal changes necessary to make it work for tmpfs (e.g. replacing read_mapping_page() with shmem_read_mapping_page()). Other than with trivial operations, this patch set has been tested with the xfstests-dev testsuite, also under severe memory pressure to ensure that everything still works when a page is swapped out. Make the following changes: provide the fsverity_get_file_digest() and fsverity_sig_validated() for IPE to retrieve fsverity information at usage time, and additionally revalidate the signature at every file open (patches 1, 2); make fsverity suitable to protect files in the rootfs filesystem (patch 3); fix a small problem in shmem_read_mapping_page_gfp() (patch 4) and finally add support for fsverity in tmpfs (patch 5). An open point, not addressed by this patch set, is how to enable the fsverity protection for files in the rootfs filesystem, given that it is too early for user space to invoke the ioctl() system call. It should not be a problem to enable fsverity from the kernel, depending on a labelling policy. Roberto Sassu (5): fsverity: Introduce fsverity_get_file_digest() fsverity: Revalidate built-in signatures at file open fsverity: Do initialization earlier shmem: Avoid segfault in shmem_read_mapping_page_gfp() shmem: Add fsverity support Documentation/filesystems/fsverity.rst | 18 ++ MAINTAINERS | 1 + fs/Kconfig | 7 + fs/verity/enable.c | 6 +- fs/verity/fsverity_private.h | 7 +- fs/verity/init.c | 2 +- fs/verity/open.c | 43 +++- fs/verity/signature.c | 6 +- include/linux/fsverity.h | 16 ++ include/linux/shmem_fs.h | 27 +++ mm/Makefile | 2 + mm/shmem.c | 71 ++++++- mm/shmem_verity.c | 267 +++++++++++++++++++++++++ 13 files changed, 463 insertions(+), 10 deletions(-) create mode 100644 mm/shmem_verity.c