Re: [PATCH 27/29] xfs: make it possible to disable fsverity

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Apr 02, 2024 at 04:25:10PM -0700, Eric Biggers wrote:
> On Fri, Mar 29, 2024 at 05:43:06PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Create an experimental ioctl so that we can turn off fsverity.
> 
> The concept of "experimental ioctls" seems problematic.  What if people start
> relying on them?  Linux tends not to have "experimental" system calls, and
> probably for good reason...

They're trapped in my enormous backlog of patches.  They get this
special treatment so that I can show them to developers without anyone
getting any fancy ideas about merging them.  Once I get close enough to
actually consider merging it, I'll move it out from under EXPERIMENTAL.

IOWs: I'm not planning to push xfs_fs_staging.h itself to upstream ever.

> Also, what is the use case for this ioctl?  Is it necessary to have this when
> userspace can already just replace a verity file with a copy that has verity
> disabled?  That's less efficient, but it does not require any kernel support and
> does not require CAP_SYS_ADMIN.

No, of course it isn't needed if replacing the file is easy.  That
however assumes that replacing /is/ easy.

The use case for this is: "I enabled fsverity on my backup volume so I
could detect bitrot, then the primary disk died, and when I went to
restore the primary, I got a verity error."

Being able to read known-bad corrupted contents are less bad than losing
the entire file or having to do surgery with xfs_db to turn off
fsverity.

Just for my own convenience, this would enable me to try out fsverity in
a few places while being able to undo it quickly if <cough> we end up
changing the ondisk format during review.

> And of course, if do we add this ioctl it shouldn't be XFS-specific.

Yes, this is a proof of concept.  I'd lift it to fs/verity/ if you
accept the premise.

--D

> - Eric
>