Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1906798imd; Fri, 2 Nov 2018 02:42:02 -0700 (PDT) X-Google-Smtp-Source: AJdET5f98raEb85CUWUikMZeTQTtCakTBcjCxHeACrMEOBPwS7S8Y0JuuL4V/hySivhnh2U/krfA X-Received: by 2002:a17:902:82ca:: with SMTP id u10-v6mr10662368plz.146.1541151722557; Fri, 02 Nov 2018 02:42:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541151722; cv=none; d=google.com; s=arc-20160816; b=jLuOP998hOHffYkM10mlBVdMjgJHKLgrYl1gpp9gk8kxURuCrPXe0W7q7mV/6WJ3xd CqcrcV/9YGIczTvfPxraMbChQGgsYTFEuqNTfRg16YPxwdr5PbcVtegT62mkeVNU0UBx ENjH74m4KdG9Zz3C5Lsbts6t28nzXCKRW6wO0I8onUcyIejEWKUBsVW0BZHcs8jfRDxc W6b4dibwsHfVkOfSPrlgCX2VY913vKuP/oImPWyDuOA8O2vrgbCU8nc4iYbZqpE3zf5U /pxZWY8UVcCbwP1fzcv2FaQJcOEQz/ni1eSQFa6kIzngWa4j8eMgCKpOxncPMNY8qAhz Vsyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:references:in-reply-to:date:subject:cc:to:from; bh=OICHHxTCEa0UNwlYR7KUtatibmVyfU8hU87/e2Q4wTg=; b=EyA0Zv4KGatTGQPvEA+2ABiQFdNJgHh6/TMap2iU42F4pRnbAgMZWK7ZKBErfcB4Pn Bgi8BjRJUUmpgvJKTb5Vq6src+qKcpwO1pSHDD6O3CShDdhU9qDJkxhNZlIkCUUCfNex EuWGOiETbwF6pHMpbh1t79FpNhSwYJ1mOxq6o/p1bmKAgecwg5/I3Gb3Q+IR/0LC9kwR KBWL3q+Rg2xtqbh0OUfm46EbPyRr8LL3Duoe9AuQITKVdIse1Ih1OyMQxouDfh1RzzCb 8rAnGWzVE9NeTEAdwbCZZn9PY+88sXV/60lkGbyOKSEuItGs4dv5x2Bp8dEUx0Mzqwn5 YQ5A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k64si20695696pge.7.2018.11.02.02.41.47; Fri, 02 Nov 2018 02:42:02 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726422AbeKBSr1 (ORCPT + 99 others); Fri, 2 Nov 2018 14:47:27 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55294 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726041AbeKBSrZ (ORCPT ); Fri, 2 Nov 2018 14:47:25 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA29cffm117551 for ; Fri, 2 Nov 2018 05:40:51 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ngksx8xau-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 02 Nov 2018 05:40:51 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Nov 2018 09:40:48 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 2 Nov 2018 09:40:43 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id wA29egMk54657266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Nov 2018 09:40:43 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0DD34203F; Fri, 2 Nov 2018 09:40:42 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 83F9042041; Fri, 2 Nov 2018 09:40:42 +0000 (GMT) Received: from localhost.localdomain (unknown [9.85.72.2]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 2 Nov 2018 09:40:42 +0000 (GMT) From: Chandan Rajendra To: Eric Biggers 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 Date: Fri, 02 Nov 2018 15:13:14 +0530 In-Reply-To: <20181101225230.88058-11-ebiggers@kernel.org> References: <20181101225230.88058-1-ebiggers@kernel.org> <20181101225230.88058-11-ebiggers@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-GCONF: 00 x-cbid: 18110209-0028-0000-0000-00000311ADE1 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18110209-0029-0000-0000-000023CDE735 Message-Id: <2168901.PE78DCQIza@localhost.localdomain> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-02_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811020091 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? -- chandan