archive mirror
 help / color / mirror / Atom feed
From: Colin Walters <>
To: Eric Biggers <>,,,
	Mimi Zohar <>,
	Dmitry Kasatkin <>,
	Michael Halcrow <>,
	Victor Hsieh <>
Subject: Re: [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig
Date: Fri, 24 Aug 2018 13:42:29 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Aug 24, 2018, at 12:16 PM, Eric Biggers wrote:
> From: Eric Biggers <>
> fs-verity is a filesystem feature that provides efficient, transparent
> integrity verification and authentication of read-only files.  It uses a
> dm-verity like mechanism at the file level: a Merkle tree hidden past
> the end of the file is used to verify any block in the file in
> log(filesize) time.  It is implemented mainly by helper functions in
> fs/verity/ that will be shared by multiple filesystems.
> Essentially, fs-verity reports a file's hash in constant time, but reads
> that would violate that hash fail at runtime.  This is useful when only
> a portion of the file is actually accessed, as only the accessed portion
> has to be hashed, and the latency to the first read is much reduced over
> a full file hash.  On top of this hashing mechanism, auditing or
> authentication policies can be implemented to log or verify file hashes.
> Note that in general, fs-verity is *not* a replacement for IMA.
> fs-verity is a lower-level feature, primarily a way to hash a file;
> whereas IMA deals more with higher-level policy logic, like defining
> which files are "measured" and what to do with those measurements.  We
> plan for IMA to support fs-verity measurements as an alternative to the
> traditional full file hash.  Still, some users find fs-verity useful by
> itself, so it's also usable without IMA in simple cases, e.g. in cases
> where just retrieving the file measurement via an ioctl is enough.
> A structure containing the properties of the Merkle tree -- such as the
> hash algorithm used, the block size, and the root hash -- is also stored
> on-disk, following the Merkle tree.  The actual file measurement hash
> that fs-verity reports is the hash of this structure.
> All fs-verity metadata is written by userspace; the kernel only reads
> it.  Extended attributes aren't used because the Merkle tree may be much
> larger than XATTR_SIZE_MAX, we want the hash pages to be cached in the
> page cache as usual, and in the case of fs-verity combined with fscrypt
> we want the metadata to be encrypted to avoid leaking plaintext hashes.
> The fs-verity metadata is hidden from userspace by overriding the i_size
> of the in-memory VFS inode; ext4 additionally will override the on-disk
> i_size in order to make verity a RO_COMPAT filesystem feature.
> This initial patch only adds the fs-verity Kconfig option, UAPI, and
> setup code, e.g. the ->open() hook that parses the fs-verity descriptor.

This first patch also adds a bit of core logic in the
simple fsverity_prepare_setattr() which ends up being called
by ext4 later.

While I'm not too familiar with the vfs, as far as I can
tell  from inspection of Linus' git master is that pretty much any change (timestamp, hardlinks) ends up
calling notify_change() which calls the fs-specific one, and in
the verity case basically denies everything, right?

Previously I brought up many uses for "content immutable" files:

The discussion sort of died out but...did you have any opinion
on e.g. my proposal to use the Unix mode bits as a way to describe
levels of mutablility?

Let's say that your new _VERITY inode flag becomes "_WRITEPROT"
or something a bit more generic.

Do you have any thoughts on my proposal to reuse the Unix mode
bits to control levels of inode mutability?

For example, it seems to me we could define u+w as "hardlinks are OK".
There shouldn't be any reason ext4/f2fs couldn't hardlink a verity-protected
inode right?  Or if for some reason that is hard, we could disallow that to
start, but at least have the core VFS support _WRITEPROT inodes?

  parent reply	other threads:[~2018-08-24 21:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-24 16:16 [RFC PATCH 00/10] fs-verity: filesystem-level integrity protection Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig Eric Biggers
2018-08-24 17:28   ` Randy Dunlap
2018-08-24 17:42   ` Colin Walters [this message]
2018-08-24 22:45     ` Theodore Y. Ts'o
2018-08-25  4:48     ` Eric Biggers
2018-09-14 13:15       ` Colin Walters
2018-09-14 16:21         ` Eric Biggers
2018-09-15 15:27           ` Theodore Y. Ts'o
2018-08-26 16:22   ` Chuck Lever
2018-08-26 17:17     ` Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 02/10] fs-verity: add data verification hooks for ->readpages() Eric Biggers
2018-08-25  2:29   ` [f2fs-dev] " Gao Xiang
2018-08-25  3:45     ` Theodore Y. Ts'o
2018-08-25  4:00       ` Gao Xiang
2018-08-25  5:06         ` Theodore Y. Ts'o
2018-08-25  7:33           ` Gao Xiang
2018-08-25  7:55             ` Gao Xiang
2018-08-25  4:16     ` Eric Biggers
2018-08-25  6:31       ` Gao Xiang
2018-08-25  7:18         ` Eric Biggers
2018-08-25  7:43           ` Gao Xiang
2018-08-25 17:06             ` Theodore Y. Ts'o
2018-08-26 13:44               ` Gao Xiang
2018-09-02  2:35       ` Olof Johansson
2018-08-26 15:55   ` Chuck Lever
2018-08-26 17:04     ` Eric Biggers
2018-08-26 17:44       ` Gao Xiang
2018-08-24 16:16 ` [RFC PATCH 03/10] fs-verity: implement FS_IOC_ENABLE_VERITY ioctl Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 04/10] fs-verity: implement FS_IOC_MEASURE_VERITY ioctl Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 05/10] fs-verity: add SHA-512 support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 06/10] fs-verity: add CRC-32C support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 07/10] fs-verity: support builtin file signatures Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 08/10] ext4: add basic fs-verity support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 09/10] ext4: add fs-verity read support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 10/10] f2fs: fs-verity support Eric Biggers
2018-08-25  5:54   ` [f2fs-dev] " Chao Yu
2018-08-26 17:35     ` Eric Biggers
2018-08-27 15:54       ` Chao Yu
2018-08-28  7:27         ` Jaegeuk Kim
2018-08-28  9:20           ` Chao Yu
2018-08-28 17:01             ` Jaegeuk Kim
2018-08-29  1:22               ` Chao Yu
2018-08-29  1:43                 ` Jaegeuk Kim
2018-08-31 20:05 ` [RFC PATCH 00/10] fs-verity: filesystem-level integrity protection Jan Lübbe
2018-08-31 21:39   ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).