[v4,0/3] ovl: Add support for fs-verity checking of lowerdata

Message

Alexander Larsson June 20, 2023, 10:15 a.m. UTC

This patchset adds support for using fs-verity to validate lowerdata
files by specifying an overlay.verity xattr on the metacopy
files.

This is primarily motivated by the Composefs usecase, where there will
be a read-only EROFS layer that contains redirect into a base data
layer which has fs-verity enabled on all files. However, it is also
useful in general if you want to ensure that the lowerdata files
matches the expected content over time.

I have also added some tests for this feature to xfstests[1].

This series depends on the commit
  fsverity: rework fsverity_get_digest() again
Which is in the "for-next" branch of 
  https://git.kernel.org/pub/scm/fs/fsverity/linux.git/

This series, plus the above commit are also in git here:
  https://github.com/alexlarsson/linux/tree/overlay-verity

I would love to see this go into 6.5. So Eric, could you maybe Ack the
implementation patches separately from the documentation patches? Then
maybe we can get this in early, and I promise to try to get the
documentation up to standard during the 6.5 cycle as needed.

Changes since v3:
 * Instead of using a overlay.digest xattr we extend the current
   overlay.metacopy xattr with version, flags and digest. This makes
   it flexible for later changes and allows us to use the existing
   xattr lookup to know ahead of time whether a file needs to have
   verity validated.

   I've done some performance checks on this new layout, and the
   results are essentially the same as before.

 * This is rebased on top of the latest overlayfs-next, which includes
   the changes to the new mount API, so that part has been redone.

 * The documentation changes have been rewritten to try to be more
   clear about the behaviour of i/o verification when verity is used.

Changes since v2:
 * Rebased on top of overlayfs-next
 * We now alway do verity verification the first time the file content
   is used, rather than doing it at lookup time for the non-lazy lookup
   case.

Changes since v1:
 * Rebased on v2 lazy lowerdata series
 * Dropped the "validate" mount option variant. We now only support
   "off", "on" and "require", where "off" is the default.
 * We now store the digest algorithm used in the overlay.verity xattr.
 * Dropped ability to configure default verity options, as this could
   cause problems moving layers between machines.
 * We now properly resolve dependent mount options by automatically
   enabling metacopy and redirect_dir if verity is on, or failing
   if the specified options conflict.
 * Streamlined and fixed the handling of creds in ovl_ensure_verity_loaded().
 * Renamed new helpers from ovl_entry_path_ to ovl_e_path_

[1] https://github.com/alexlarsson/xfstests/commits/verity-tests

Alexander Larsson (3):
  ovl: Add framework for verity support
  ovl: Validate verity xattr when resolving lowerdata
  ovl: Handle verity during copy-up

 Documentation/filesystems/fsverity.rst  |   2 +
 Documentation/filesystems/overlayfs.rst |  48 ++++++++
 fs/overlayfs/copy_up.c                  |  47 ++++++-
 fs/overlayfs/file.c                     |   8 +-
 fs/overlayfs/namei.c                    |  97 +++++++++++++--
 fs/overlayfs/overlayfs.h                |  53 ++++++--
 fs/overlayfs/ovl_entry.h                |   1 +
 fs/overlayfs/super.c                    |  69 +++++++++--
 fs/overlayfs/util.c                     | 156 +++++++++++++++++++++++-
 9 files changed, 448 insertions(+), 33 deletions(-)

Comments

Eric Biggers June 20, 2023, 4:15 p.m. UTC | #1

On Tue, Jun 20, 2023 at 12:15:15PM +0200, Alexander Larsson wrote:
> This series depends on the commit
>   fsverity: rework fsverity_get_digest() again
> Which is in the "for-next" branch of 
>   https://git.kernel.org/pub/scm/fs/fsverity/linux.git/
> 
> This series, plus the above commit are also in git here:
>   https://github.com/alexlarsson/linux/tree/overlay-verity
> 
> I would love to see this go into 6.5. So Eric, could you maybe Ack the
> implementation patches separately from the documentation patches? Then
> maybe we can get this in early, and I promise to try to get the
> documentation up to standard during the 6.5 cycle as needed.

I think it's gotten too late for 6.5.  If there is no 6.4-rc8, then the 6.5
merge window will open just 5 days from now.  This series has recently gone
through some significant changes, including in the version just sent out today
which I haven't had a chance to review yet.

Please don't try to rush things in when they involve UAPI and on-disk format
changes, which will have to be supported forever.  We need to take the time to
get them right.
 
I also see that the overlayfs tree is already very busy in 6.5, with the support
for data-only lower layers, lazy lookup of lowerdata, and the new mount API.

I think 6.6 would be a more realistic target.  That would give time to write
proper documentation as well, which is super important.  (Very often while
writing documentation, I realize that I should do something differently in the
code.  Please don't think of documentation as something can be done "later".)

- Eric

Alexander Larsson June 21, 2023, 11:27 a.m. UTC | #2

On Tue, Jun 20, 2023 at 6:15 PM Eric Biggers <[e-mail]> wrote:
>
> On Tue, Jun 20, 2023 at 12:15:15PM +0200, Alexander Larsson wrote:
> > This series depends on the commit
> >   fsverity: rework fsverity_get_digest() again
> > Which is in the "for-next" branch of
> >   https://git.kernel.org/pub/scm/fs/fsverity/linux.git/
> >
> > This series, plus the above commit are also in git here:
> >   https://github.com/alexlarsson/linux/tree/overlay-verity
> >
> > I would love to see this go into 6.5. So Eric, could you maybe Ack the
> > implementation patches separately from the documentation patches? Then
> > maybe we can get this in early, and I promise to try to get the
> > documentation up to standard during the 6.5 cycle as needed.
>
> I think it's gotten too late for 6.5.  If there is no 6.4-rc8, then the 6.5
> merge window will open just 5 days from now.  This series has recently gone
> through some significant changes, including in the version just sent out today
> which I haven't had a chance to review yet.
>
> Please don't try to rush things in when they involve UAPI and on-disk format
> changes, which will have to be supported forever.  We need to take the time to
> get them right.
>
> I also see that the overlayfs tree is already very busy in 6.5, with the support
> for data-only lower layers, lazy lookup of lowerdata, and the new mount API.
>
> I think 6.6 would be a more realistic target.  That would give time to write
> proper documentation as well, which is super important.  (Very often while
> writing documentation, I realize that I should do something differently in the
> code.  Please don't think of documentation as something can be done "later".)

If 6.6 is what ends up happening I'm not gonna protest, it's not a
huge issue for me, only mildly inconvenient. But, for now I'll at
least keep targeting 6.5, and then we will have to see how it works
out wrt reviews and what Miklos decides.

I pushed out a v5 series today too, because the v4 series conflicted
with some other changes in vfs.all that are staged for 6.5. v5 is also
a bit simplified based on Amirs feedback, has some documentation
updates and is refactored into more commits for easier review.

Amir Goldstein June 21, 2023, 12:57 p.m. UTC | #3

On Wed, Jun 21, 2023 at 2:27 PM Alexander Larsson <[e-mail]> wrote:
>
> On Tue, Jun 20, 2023 at 6:15 PM Eric Biggers <[e-mail]> wrote:
> >
> > On Tue, Jun 20, 2023 at 12:15:15PM +0200, Alexander Larsson wrote:
> > > This series depends on the commit
> > >   fsverity: rework fsverity_get_digest() again
> > > Which is in the "for-next" branch of
> > >   https://git.kernel.org/pub/scm/fs/fsverity/linux.git/
> > >
> > > This series, plus the above commit are also in git here:
> > >   https://github.com/alexlarsson/linux/tree/overlay-verity
> > >
> > > I would love to see this go into 6.5. So Eric, could you maybe Ack the
> > > implementation patches separately from the documentation patches? Then
> > > maybe we can get this in early, and I promise to try to get the
> > > documentation up to standard during the 6.5 cycle as needed.
> >
> > I think it's gotten too late for 6.5.  If there is no 6.4-rc8, then the 6.5
> > merge window will open just 5 days from now.  This series has recently gone
> > through some significant changes, including in the version just sent out today
> > which I haven't had a chance to review yet.
> >
> > Please don't try to rush things in when they involve UAPI and on-disk format
> > changes, which will have to be supported forever.  We need to take the time to
> > get them right.
> >
> > I also see that the overlayfs tree is already very busy in 6.5, with the support
> > for data-only lower layers, lazy lookup of lowerdata, and the new mount API.
> >
> > I think 6.6 would be a more realistic target.  That would give time to write
> > proper documentation as well, which is super important.  (Very often while
> > writing documentation, I realize that I should do something differently in the
> > code.  Please don't think of documentation as something can be done "later".)
>
> If 6.6 is what ends up happening I'm not gonna protest, it's not a
> huge issue for me, only mildly inconvenient. But, for now I'll at
> least keep targeting 6.5, and then we will have to see how it works
> out wrt reviews and what Miklos decides.
>
> I pushed out a v5 series today too, because the v4 series conflicted
> with some other changes in vfs.all that are staged for 6.5. v5 is also
> a bit simplified based on Amirs feedback, has some documentation
> updates and is refactored into more commits for easier review.
>

I reviewed v5 and it is all fine by me, but I do agree with Eric that
it has become quite late for 6.5 and other reviewers need to get
enough time to review v5, so no need to rush.

I also need some time to test verity feature which I hadn't had
the chance to do yet, so it looks like the stars are aligned for 6.6.
I am planning to be on vacation around 6.5-rc2..6.5-rc6 -
because of your efforts to get the patches ready in time for 6.5,
I will now have time to test your patches before -rc6, so your
efforts have not been in vain...

Thanks,
Amir.