Re: [PATCH v3 2/4] ovl: Add framework for verity support

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Jun 16, 2023 at 10:11:06AM +0200, Alexander Larsson wrote:
> On Fri, Jun 16, 2023 at 1:52 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Wed, Jun 14, 2023 at 09:57:41AM +0200, Alexander Larsson wrote:
> > > 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, then opening the corresponding file on
> > > overlayfs will result in EIO and a detailed error printed to the kernel logs.
> > > (Actually, due to caching the overlayfs mount might still see the previous
> > > file contents after a lower file is replaced under an active mount, but
> > > it will never see the wrong data.)
> >
> > Well, the key point of fsverity is that data is not verified until it is
> > actually read.  At open time, the fsverity file digest is made available in
> > constant time, and overlayfs will verify that.  However, invalid data blocks are
> > not reported until the data is actually read.  The error that applications get
> > is EIO for syscalls, and SIGBUS for memory-mapped reads, as mentioned at
> > https://www.kernel.org/doc/html/latest/filesystems/fsverity.html#accessing-verity-files
> >
> > So overlayfs might report EIO at open time, or it might not report an error
> > until the modified data is read.  And in the latter case, presumably the error
> > seen by the application matches the one for using fsverity natively?
> 
> Yes, I'm aware of that, but do we need to describe this in the
> overlayfs documentation?
> The text I wrote is describing the behaviour that overlayfs adds to
> the mix, and I sort of
> assumed the late validation from fs-verity itself would be known about
> if the file already
> has fs-verity enabled.
> 
> > You can link to the fsverity documentation somewhere if it would be helpful, but
> > I'd still like the semantics of how this works on overlayfs to be documented.
> 
> I guess just adding a link to that is not that bad. What about:
> 
> ----
> 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, then opening the corresponding file
> on overlayfs will result in EIO and a detailed error printed to the
> kernel logs.  (Actually, due to caching the overlayfs mount might
> still see the previous file contents after a lower file is replaced
> under an active mount, but it will never see the wrong data.)  In
> addition fs-verity will do late validation of the file content, as
> described in :ref:`Documentation/filesystems/fsverity.rst
> <accessing_verity_files>`.

That still has the incorrect statement "If at any time (during a mount, after a
remount, etc) such a file in the lower is replaced or modified in any way, then
opening the corresponding file on overlayfs will result in EIO and a detailed
error printed to the kernel logs."  See my last email where I explained why that
statement is not correct.

- Eric