On Sat, Jun 17, 2023 at 9:47 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> 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. If the modification of the file happens via the kernel vfs API, then the new backing file will have either have no, or the wrong fs-verity digest, which will be reported by overlayfs on open. It is true that a modification on the block level which the vfs is unaware of will be reported at read time, by fs-verity (i.e. independent of overlayfs). This is what I meant by the "in addition .." part, but maybe that is not clear. I'll try to rephrase it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
