linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: Sarthak Kukreti <sarthakkukreti@chromium.org>,
	tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] tune2fs: allow remove VERITY
Date: Wed, 24 Jun 2020 09:09:26 -0700	[thread overview]
Message-ID: <20200624160926.GA200774@gmail.com> (raw)
In-Reply-To: <CAPUE2uv0XXv40quqbKmdktgCD18DnSWh=Ekeiq2tAZOfmGmjGw@mail.gmail.com>

On Wed, Jun 24, 2020 at 12:06:22AM -0700, Gwendal Grignou wrote:
> On Tue, Jun 23, 2020 at 7:40 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Tue, Jun 23, 2020 at 07:31:07PM -0700, Gwendal Grignou wrote:
> > > Allow verity flag to be removed from the susperblock:
> > > Tests:
> > > - check the signed file is readable by older kernel after flag
> > > is removed. EXT4_VERITY_FL replaces EXT4_EXT_MIGRATE that has been
> > > removed in 2009.
> > > - when a new kernel is reinstalled, check reenabling verity flag
> > > allow signature to be verified (fsverity measure ...).
> > >
> > > Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> > > ---
> > >  misc/tune2fs.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/misc/tune2fs.c b/misc/tune2fs.c
> > > index 314cc0d0..724b8014 100644
> > > --- a/misc/tune2fs.c
> > > +++ b/misc/tune2fs.c
> > > @@ -198,7 +198,8 @@ static __u32 clear_ok_features[3] = {
> > >               EXT4_FEATURE_RO_COMPAT_QUOTA |
> > >               EXT4_FEATURE_RO_COMPAT_PROJECT |
> > >               EXT4_FEATURE_RO_COMPAT_METADATA_CSUM |
> > > -             EXT4_FEATURE_RO_COMPAT_READONLY
> > > +             EXT4_FEATURE_RO_COMPAT_READONLY |
> > > +             EXT4_FEATURE_RO_COMPAT_VERITY
> > >  };
> > >
> >
> > tune2fs doesn't allow removing features like encrypt, casefold, verity, extents,
> > and ea_inode because it doesn't know whether there are any inodes on the
> > filesystem that are using these features.  These features can't be removed if
> > there are any inodes using them.
>
> The verity case is slightly different though: beside metadata,
> encrypted files are useless.
> In the case of fs-verity, the file is still readable, its size is
> correct. Using debugfs, I checked the merkel tree blocks appended at
> the end of the file are still mapped to the file inode, they are
> marked as free when the file is removed.
> Are you concerned about filesystem corruption? When I re-enable the
> features and load a kernel that supports fs-verity, the protected
> files are signed and read-only as expected.

The problem is that the old, non-verity-aware kernel will allow writing to
verity files, because it ignores the verity inode flag.  That will get files'
data out of sync with their Merkle trees, and possibly corrupt their Merkle
trees.

This is why verity is a RO_COMPAT feature rather than a COMPAT one.  This
ensures that if the kernel isn't aware of verity, then the filesystem can only
be mounted read-only.

How about making 'tune2fs -O ^verity' remove the verity flag from all files
that have it and remove their Merkle trees by truncating blocks past i_size?
Would that work for you, or do you really need the verity-ness of files to be
preserved over 'tune2fs -O ^verity; tune2fs -O verity'?

- Eric

  reply	other threads:[~2020-06-24 16:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  2:31 [PATCH] tune2fs: allow remove VERITY Gwendal Grignou
2020-06-24  2:40 ` Eric Biggers
2020-06-24  7:06   ` Gwendal Grignou
2020-06-24 16:09     ` Eric Biggers [this message]
2020-06-25 18:26       ` Gwendal Grignou
2020-06-26 18:56         ` Eric Biggers

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=20200624160926.GA200774@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=gwendal@chromium.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sarthakkukreti@chromium.org \
    --cc=tytso@mit.edu \
    /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).