Linux Overlay Filesystem development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Alexander Larsson <alexl@redhat.com>
Cc: miklos@szeredi.hu, linux-unionfs@vger.kernel.org,
	amir73il@gmail.com, tytso@mit.edu, fsverity@lists.linux.dev
Subject: Re: [PATCH v4 1/4] ovl: Add framework for verity support
Date: Mon, 3 Jul 2023 12:08:59 -0700	[thread overview]
Message-ID: <20230703190859.GB1194@sol.localdomain> (raw)
In-Reply-To: <8bbfe13980cc9aa70e347811280b62eba930ffd2.1687345663.git.alexl@redhat.com>

On Wed, Jun 21, 2023 at 01:18:25PM +0200, Alexander Larsson wrote:
> diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
> index eb7d2c88ddec..b63e0db03631 100644
> --- a/Documentation/filesystems/overlayfs.rst
> +++ b/Documentation/filesystems/overlayfs.rst
> @@ -405,6 +405,53 @@ when a "metacopy" file in one of the lower layers above it, has a "redirect"
>  to the absolute path of the "lower data" file in the "data-only" lower layer.
>  
>  
> +fs-verity support
> +----------------------
> +
> +During metadata copy up of a lower file, if the source file has
> +fs-verity enabled and overlay verity support is enabled, then the
> +digest of the lower file is added to the "trusted.overlay.metacopy"
> +xattr. This is then used to verify the content of the lower file
> +each the time the metacopy file is opened.
> +
> +When a layer containing verity xattrs is used, it means that any such
> +metacopy file in the upper layer is guaranteed to match the content
> +that was in the lower at the time of the copy-up. If at any time
> +(during a mount, after a remount, etc) such a file in the lower is
> +replaced or modified in any way, access to the corresponding file in
> +overlayfs will result in EIO errors (either on open, due to overlayfs
> +digest check, or from a later read due to fs-verity) and a detailed
> +error is printed to the kernel logs. For more details of how fs-verity
> +file access works, see :ref:`Documentation/filesystems/fsverity.rst
> +<accessing_verity_files>`.
> +
> +Verity can be used as a general robustness check to detect accidental
> +changes in the overlayfs directories in use. But, with additional care
> +it can also give more powerful guarantees. For example, if the upper
> +layer is fully trusted (by using dm-verity or something similar), then
> +an untrusted lower layer can be used to supply validated file content
> +for all metacopy files.  If additionally the untrusted lower
> +directories are specified as "Data-only", then they can only supply
> +such file content, and the entire mount can be trusted to match the
> +upper layer.
> +
> +This feature is controlled by the "verity" mount option, which
> +supports these values:
> +
> +- "off":
> +    The metacopy digest is never generated or used. This is the
> +    default if verity option is not specified.
> +- "on":
> +    Whenever a metacopy files specifies an expected digest, the
> +    corresponding data file must match the specified digest. When
> +    generating a metacopy file the verity digest will be set in it
> +    based on the source file (if it has one).
> +- "require":
> +    Same as "on", but additionally all metacopy files must specify a
> +    digest (or EIO is returned on open). This means metadata copy up
> +    will only be used if the data file has fs-verity enabled,
> +    otherwise a full copy-up is used.
> +

Thanks, it's not perfect but it's much improved.

Acked-by: Eric Biggers <ebiggers@google.com>

- Eric

  parent reply	other threads:[~2023-07-03 19:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21 11:18 [PATCH v5 0/4] ovl: Add support for fs-verity checking of lowerdata Alexander Larsson
2023-06-21 11:18 ` [PATCH v4 1/4] ovl: Add framework for verity support Alexander Larsson
2023-06-21 12:18   ` Amir Goldstein
2023-07-03 19:08   ` Eric Biggers [this message]
2023-06-21 11:18 ` [PATCH v4 2/4] ovl: Add versioned header for overlay.metacopy xattr Alexander Larsson
2023-06-21 12:21   ` Amir Goldstein
2023-07-03 19:13   ` Eric Biggers
2023-07-05  8:07     ` Alexander Larsson
2023-07-05 13:12       ` Amir Goldstein
2023-06-21 11:18 ` [PATCH v4 3/4] ovl: Validate verity xattr when resolving lowerdata Alexander Larsson
2023-06-21 12:24   ` Amir Goldstein
2023-07-03 19:24   ` Eric Biggers
2023-07-05  9:09     ` Alexander Larsson
2023-06-21 11:18 ` [PATCH v4 4/4] ovl: Handle verity during copy-up Alexander Larsson
2023-06-21 12:26   ` Amir Goldstein
2023-07-03 19:29   ` Eric Biggers
2023-07-05  9:11     ` Alexander Larsson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20230703190859.GB1194@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=alexl@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=fsverity@lists.linux.dev \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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