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. - Eric
