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>`. --- -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
