Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1272322imu; Mon, 5 Nov 2018 17:25:49 -0800 (PST) X-Google-Smtp-Source: AJdET5cV2Lmtz7NplT2vQKk9Uu5TYx3D4NtO714XBemc0rF1idOvkmpmKBuow355w5gjzwk+fUII X-Received: by 2002:a17:902:6948:: with SMTP id k8-v6mr24574621plt.22.1541467549722; Mon, 05 Nov 2018 17:25:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541467549; cv=none; d=google.com; s=arc-20160816; b=SgNxXlsoURPCv9n1MmSn+AE7cjk/xtNhUoO8P0+Wj13At2a62Xvzqtu2DEJP6Kjydh ULBUYE9OtyAxrWhIALLfJ+UAsEpId/E1tZNB0mFq2Pkknfoefiz/ylM8ExkWFFlDgPby UcFTkouMQyZiwKfvkruEgOR9smjRf3jWqP4gbwmH6XOMLED5XllXPsyBuAurS+vTLBrw XA60fYtaXtAUubKll7DS8zNgzsXdLEs+uXzehUwdWlTnw24Iu9xFHvOKpyCpZicTD39K OCCIAUvlaZ4sRqGOx2aNMNI4gSXL6rOhXS6kg/eMq5orzR+mGR9fMNKk/gxd4WEMdyFc gc6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=cFxoarbMALMGaX0vptdCIQ/3ZOokNBENxuquXqClviQ=; b=TUBvL/tOOOtPQJUzJ1FjSA06eAWStzL5Du2+xXb7+x8MHsoHq+b+SHX2j0gl/o4qRx 6NuwWtkbB8F3HaQ7e+k6SHOgCHrd2bKI18WgxqPdEu7iHBwq/jXeRfM9UrhIw3wnGJkz aA2nkqU0z5qK7r3SGI7RujXp47rqm5hx2+BC+rgHwZ4Y0cCjx2/geCwIS6DFb2/n8Yy1 Pa0fRo3z0/ZHqB7eozyzpNZO+CNJxeVQ1FCUaV672JipKPJsj/QITEbtgtGwgJ3CQXRH IcEHr4By0sLHGo19NvKLIjI4Fe/k+ROuo6hBW0vTDy7TSLqSfK3bb505Eo835bAgfaa3 5/wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="qkIe1/Zc"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3-v6si46111955pgn.313.2018.11.05.17.25.30; Mon, 05 Nov 2018 17:25:49 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b="qkIe1/Zc"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727435AbeKFKrn (ORCPT + 99 others); Tue, 6 Nov 2018 05:47:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:53140 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726092AbeKFKrm (ORCPT ); Tue, 6 Nov 2018 05:47:42 -0500 Received: from gmail.com (unknown [104.132.51.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 40DF32083D; Tue, 6 Nov 2018 01:25:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541467505; bh=QjVe8u1g76rS0Ee0gKJLnQuSNgECPZVc0CidCt+4Gu4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qkIe1/ZcLIdorXnbBaBcZsC+VF0hG9GYvMfhhGqE0z592YDbCdr+bnNh4VES3CEkG C87QAM/CDlopagJypUN5kqHVpC45az7pvKmCrP0flm8QS8fuBWQINTLZMl4HFvFZiD nhGXvEEzEtzEYCBlO6VdKlErLxZ8DOh5wjW7TFsc= Date: Mon, 5 Nov 2018 17:25:03 -0800 From: Eric Biggers To: Chandan Rajendra Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, "Theodore Y . Ts'o" , Jaegeuk Kim , Victor Hsieh Subject: Re: [PATCH v2 10/12] ext4: add basic fs-verity support Message-ID: <20181106012503.GB28490@gmail.com> References: <20181101225230.88058-1-ebiggers@kernel.org> <20181101225230.88058-11-ebiggers@kernel.org> <2168901.PE78DCQIza@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2168901.PE78DCQIza@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chandan, On Fri, Nov 02, 2018 at 03:13:14PM +0530, Chandan Rajendra wrote: > On Friday, November 2, 2018 4:22:28 AM IST Eric Biggers wrote: > > From: Eric Biggers > > > > Add basic fs-verity support to ext4. fs-verity is a filesystem feature > > that enables transparent integrity protection and authentication of > > read-only files. It uses a dm-verity like mechanism at the file level: > > a Merkle tree is used to verify any block in the file in log(filesize) > > time. It is implemented mainly by helper functions in fs/verity/. > > See Documentation/filesystems/fsverity.rst for details. > > > > This patch adds everything except the data verification hooks that will > > needed in ->readpages(). > > > > On ext4, enabling fs-verity on a file requires that the filesystem has > > the 'verity' feature, e.g. that it was formatted with > > 'mkfs.ext4 -O verity' or had 'tune2fs -O verity' run on it. > > This requires e2fsprogs 1.44.4-2 or later. > > > > In ext4, we choose to retain the fs-verity metadata past the end of the > > file rather than trying to move it into an external inode xattr, since > > in practice keeping the metadata in-line actually results in the > > simplest and most efficient implementation. One non-obvious advantage > > of keeping the verity metadata in-line is that when fs-verity is > > combined with fscrypt, the verity metadata naturally gets encrypted too; > > this is actually necessary because it contains hashes of the plaintext. > > > > We also choose to keep the on-disk i_size equal to the original file > > size, in order to make the 'verity' feature a RO_COMPAT feature. Thus, > > ext4 has to find the fsverity_footer by looking in the last extent. > > > > Co-developed-by: Theodore Ts'o > > Signed-off-by: Theodore Ts'o > > Signed-off-by: Eric Biggers > > --- > > fs/ext4/Kconfig | 20 +++++++++++ > > fs/ext4/ext4.h | 20 ++++++++++- > > fs/ext4/file.c | 6 ++++ > > fs/ext4/inode.c | 8 +++++ > > fs/ext4/ioctl.c | 12 +++++++ > > fs/ext4/super.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++ > > fs/ext4/sysfs.c | 6 ++++ > > 7 files changed, 162 insertions(+), 1 deletion(-) > > > > diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig > > index a453cc87082b5..5a76125ac0f8a 100644 > > --- a/fs/ext4/Kconfig > > +++ b/fs/ext4/Kconfig > > @@ -111,6 +111,26 @@ config EXT4_FS_ENCRYPTION > > default y > > depends on EXT4_ENCRYPTION > > > > +config EXT4_FS_VERITY > > + bool "Ext4 Verity" > > + depends on EXT4_FS > > + select FS_VERITY > > + help > > + This option enables fs-verity for ext4. fs-verity is the > > + dm-verity mechanism implemented at the file level. Userspace > > + can append a Merkle tree (hash tree) to a file, then enable > > + fs-verity on the file. ext4 will then transparently verify > > + any data read from the file against the Merkle tree. The file > > + is also made read-only. > > + > > + This serves as an integrity check, but the availability of the > > + Merkle tree root hash also allows efficiently supporting > > + various use cases where normally the whole file would need to > > + be hashed at once, such as auditing and authenticity > > + verification (appraisal). > > + > > + If unsure, say N. > > + > > config EXT4_DEBUG > > bool "EXT4 debugging support" > > depends on EXT4_FS > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > > index 12f90d48ba613..e5475a629ed80 100644 > > --- a/fs/ext4/ext4.h > > +++ b/fs/ext4/ext4.h > > @@ -43,6 +43,9 @@ > > #define __FS_HAS_ENCRYPTION IS_ENABLED(CONFIG_EXT4_FS_ENCRYPTION) > > #include > > > > +#define __FS_HAS_VERITY IS_ENABLED(CONFIG_EXT4_FS_VERITY) > > +#include > > + > > #include > > > > /* Until this gets included into linux/compiler-gcc.h */ > > @@ -405,6 +408,7 @@ struct flex_groups { > > #define EXT4_TOPDIR_FL 0x00020000 /* Top of directory hierarchies*/ > > #define EXT4_HUGE_FILE_FL 0x00040000 /* Set to each huge file */ > > #define EXT4_EXTENTS_FL 0x00080000 /* Inode uses extents */ > > +#define EXT4_VERITY_FL 0x00100000 /* Verity protected inode */ > > #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */ > > #define EXT4_EOFBLOCKS_FL 0x00400000 /* Blocks allocated beyond EOF */ > > #define EXT4_INLINE_DATA_FL 0x10000000 /* Inode has inline data. */ > > @@ -472,6 +476,7 @@ enum { > > EXT4_INODE_TOPDIR = 17, /* Top of directory hierarchies*/ > > EXT4_INODE_HUGE_FILE = 18, /* Set to each huge file */ > > EXT4_INODE_EXTENTS = 19, /* Inode uses extents */ > > + EXT4_INODE_VERITY = 20, /* Verity protected inode */ > > EXT4_INODE_EA_INODE = 21, /* Inode used for large EA */ > > EXT4_INODE_EOFBLOCKS = 22, /* Blocks allocated beyond EOF */ > > EXT4_INODE_INLINE_DATA = 28, /* Data in inode. */ > > @@ -517,6 +522,7 @@ static inline void ext4_check_flag_values(void) > > CHECK_FLAG_VALUE(TOPDIR); > > CHECK_FLAG_VALUE(HUGE_FILE); > > CHECK_FLAG_VALUE(EXTENTS); > > + CHECK_FLAG_VALUE(VERITY); > > CHECK_FLAG_VALUE(EA_INODE); > > CHECK_FLAG_VALUE(EOFBLOCKS); > > CHECK_FLAG_VALUE(INLINE_DATA); > > @@ -1654,6 +1660,7 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei) > > #define EXT4_FEATURE_RO_COMPAT_METADATA_CSUM 0x0400 > > #define EXT4_FEATURE_RO_COMPAT_READONLY 0x1000 > > #define EXT4_FEATURE_RO_COMPAT_PROJECT 0x2000 > > +#define EXT4_FEATURE_RO_COMPAT_VERITY 0x8000 > > > > #define EXT4_FEATURE_INCOMPAT_COMPRESSION 0x0001 > > #define EXT4_FEATURE_INCOMPAT_FILETYPE 0x0002 > > @@ -1742,6 +1749,7 @@ EXT4_FEATURE_RO_COMPAT_FUNCS(bigalloc, BIGALLOC) > > EXT4_FEATURE_RO_COMPAT_FUNCS(metadata_csum, METADATA_CSUM) > > EXT4_FEATURE_RO_COMPAT_FUNCS(readonly, READONLY) > > EXT4_FEATURE_RO_COMPAT_FUNCS(project, PROJECT) > > +EXT4_FEATURE_RO_COMPAT_FUNCS(verity, VERITY) > > > > EXT4_FEATURE_INCOMPAT_FUNCS(compression, COMPRESSION) > > EXT4_FEATURE_INCOMPAT_FUNCS(filetype, FILETYPE) > > @@ -1797,7 +1805,8 @@ EXT4_FEATURE_INCOMPAT_FUNCS(encrypt, ENCRYPT) > > EXT4_FEATURE_RO_COMPAT_BIGALLOC |\ > > EXT4_FEATURE_RO_COMPAT_METADATA_CSUM|\ > > EXT4_FEATURE_RO_COMPAT_QUOTA |\ > > - EXT4_FEATURE_RO_COMPAT_PROJECT) > > + EXT4_FEATURE_RO_COMPAT_PROJECT |\ > > + EXT4_FEATURE_RO_COMPAT_VERITY) > > > > #define EXTN_FEATURE_FUNCS(ver) \ > > static inline bool ext4_has_unknown_ext##ver##_compat_features(struct super_block *sb) \ > > @@ -2293,6 +2302,15 @@ static inline bool ext4_encrypted_inode(struct inode *inode) > > return ext4_test_inode_flag(inode, EXT4_INODE_ENCRYPT); > > } > > > > +static inline bool ext4_verity_inode(struct inode *inode) > > +{ > > +#ifdef CONFIG_EXT4_FS_VERITY > > + return ext4_test_inode_flag(inode, EXT4_INODE_VERITY); > > +#else > > + return false; > > +#endif > > +} > > + > > Hi Eric, > > Can you please explain as to why we check for the presence of > EXT4_INODE_VERITY flag only when fsverity is enabled during kernel build? > Good question, this might not be the best approach actually; I think this was originally copied from the f2fs version. It does reduce the overhead introduced by the fs-verity changes in the !CONFIG_EXT4_FS_VERITY case. But it will allow opening verity files, even for writing which will corrupt them. Probably we should make ext4_verity_inode() work regardless of CONFIG_EXT4_FS_VERITY, so open(), truncate(), etc. will fail with EOPNOTSUPP on verity files when !CONFIG_EXT4_FS_VERITY, like how ext4 encryption works. Thanks, - Eric