From: Alexander Larsson <alexl@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: WIP: verity support for overlayfs
Date: Fri, 10 Mar 2023 12:22:32 +0100 [thread overview]
Message-ID: <CAL7ro1F9Zu-m4PvHaeGvYAnFE7VaLp=Ykz8zadUWVPX-qjS7dQ@mail.gmail.com> (raw)
In-Reply-To: <CAL7ro1GQcs28kT+_2M5JQZoUN6KHYmA85ouiwjj6JU+1=C-q4g@mail.gmail.com>
On Wed, Mar 8, 2023 at 4:28 PM Alexander Larsson <alexl@redhat.com> wrote:
>
> As was recently discussed in the various threads about composefs we
> want the ability to specify a fs-verity digest for metacopy files,
> such that the lower file used for the data is guaranteed to have the
> specified digest.
>
> I wrote an initial version of this here:
>
> https://github.com/alexlarsson/linux/tree/overlay-verity
After some discussions with Amir in github I updated the branch. In
this new version there are four verity modes with this behaviour:
Unless you explicitly disable it ("verity=off") all existing xattrs
are validated before use. This is all that happens by default
("verity=validate"), but, if you turn on verity ("verity=on") then
during metacopy we generate verity xattr in the upper metacopy file (if
the source file has verity enabled). This means later accesses can
guarantee that the correct data is used.
Additionally you can use "verity=require". In this mode all metacopy
files must have a valid verity xattr. For this to work metadata
copy-up must be able to create a verity xattr (so that later accesses
are validated). Therefore, in this mode, if the lower data file
doesn't have fs-verity enabled we fall back to a full copy rather than
a metacopy.
In addition I changed the code so that validation of lowerdata happens
during lookup. Previously I was trying to do this lazily at use-time,
but that was only done partially right. Amir is doing some general
work on making lookups lazy, so the idea is to migrate the verity
validation to that later.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@redhat.com alexander.larsson@gmail.com
prev parent reply other threads:[~2023-03-10 11:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 15:28 WIP: verity support for overlayfs Alexander Larsson
2023-03-09 14:59 ` Miklos Szeredi
2023-03-09 15:26 ` Colin Walters
2023-03-09 15:57 ` Alexander Larsson
2023-03-09 15:45 ` Alexander Larsson
2023-03-10 11:22 ` Alexander Larsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL7ro1F9Zu-m4PvHaeGvYAnFE7VaLp=Ykz8zadUWVPX-qjS7dQ@mail.gmail.com' \
--to=alexl@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).