linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Biggers <ebiggers@google.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Michael Halcrow <mhalcrow@google.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-ext4@vger.kernel.org, Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH] f2fs: reserve bits for fs-verity
Date: Tue, 3 Apr 2018 07:49:59 +1000	[thread overview]
Message-ID: <20180402214959.GG18129@dastard> (raw)
In-Reply-To: <20180402184837.GA59810@google.com>

On Mon, Apr 02, 2018 at 11:48:37AM -0700, Eric Biggers wrote:
> [+Cc linux-ext4, linux-fsdevel]
> 
> On Mon, Apr 02, 2018 at 06:07:10PM +0800, Chao Yu wrote:
> > Hi Eric and Jaegeuk,
> > 
> > On 2018/3/31 2:34, Eric Biggers wrote:
> > > Hi Chao and Jaegeuk,
> > > 
> > > On Fri, Mar 30, 2018 at 09:41:36AM -0700, Jaegeuk Kim wrote:
> > >> On 03/30, Chao Yu wrote:
> > >>> Hi Eric,
> > >>>
> > >>> On 2018/3/29 2:15, Eric Biggers wrote:
> > >>>> Reserve an F2FS feature flag and inode flag for fs-verity.  This is an
> > >>>> in-development feature that is planned be discussed at LSF/MM 2018 [1].
> > >>>> It will provide file-based integrity and authenticity for read-only
> > >>>> files.  Most code will be in a filesystem-independent module, with
> > >>>> smaller changes needed to individual filesystems that opt-in to
> > >>>> supporting the feature.  An early prototype supporting F2FS is available
> > >>>> [2].  Reserving the F2FS on-disk bits for fs-verity will prevent users
> > >>>> of the prototype from conflicting with other new F2FS features.
> > >>>>
> > >>>> Note that we're reserving the inode flag in f2fs_inode.i_advise, which
> > >>>> isn't really appropriate since it's not a hint or advice.  But
> > >>>> ->i_advise is already being used to hold the 'encrypt' flag; and F2FS's
> > >>>> ->i_flags uses the generic FS_* values, so it seems ->i_flags can't be
> > >>>> used for an F2FS-specific flag without additional work to remove the
> > >>>> assumption that ->i_flags uses the generic flags namespace.
> > >>>
> > >>> At a glance, this is a VFS feature, can we search free slot, and define
> > >>> FS_VERITY_FL like other generic flags, so we can intergrate this flag into
> > >>> f2fs_inode::i_flags?
> > >>
> > >> Do we need to get/set this bit of i_flags to user? And, f2fs doesn't synchronize
> > >> it with inode block update. I think this should be set by internal f2fs
> > >> operations likewise fscrypt.
> > >>
> > > 
> > > The fs-verity inode flag won't be modifiable using FS_IOC_SETFLAGS.  Like
> > 
> > Verity flag can also be wrapped by FS_FL_USER_MODIFIABLE like for FS_ENCRYPT_FL?
> > 
> > > fscrypt, it will only be possible to set it using a dedicated ioctl (tentatively
> > > called FS_IOC_ENABLE_VERITY), and it won't be supported to clear the bit once
> > > set, short of deleting and re-creating the file.  So it doesn't really matter
> > > where the bit goes in the on-disk inode, it just needs to go somewhere.  I'm
> > > just hesitant to reserve a flag in the UAPI flags namespace which is really more
> > > "owned" by ext4 than by f2fs, so has more implications than just f2fs as we
> > > would effectively be reserving the flag for ext4's on-disk format too.
> > 
> > IMO, because this is a VFS feature, it will be better that we can put it in more
> > generic place, also user can check this bit in generic way (via
> > FS_IOC_GETFLAGS), and then for other filesystem who wants add this feature, that
> > will be simple to place this bit.
> > 
> > What I can see is, for encryption feature:
> > 
> > vfs::i_flags
> > #define FS_ENCRYPT_FL                   0x00000800 /* Encrypted file */
> > 
> > ext4:i_flags
> > #define EXT4_ENCRYPT_FL			0x00000800 /* encrypted file */
> > 
> > f2fs::i_advice
> > #define FADVISE_ENCRYPT_BIT	0x04
> > 
> > It's very wired that f2fs didn't use well defined FS_ENCRYPT_FL bit position,
> > result in that we leave a hole in on-disk i_flags, and if we want to show the
> > same 'encrypted' flags status in FS_IOC_GETFLAGS, we need to change more codes.
> > 
> > Anyway, I just ask why not let generic status goes into i_flags, and private
> > status goes into i_advices?
> 
> Ted and others, what would you say about allocating FS_VERITY_FL as one of the
> unused ext4 / "VFS" inode flags like 0x01000000, or maybe 0x00000400 if the
> compression flags aren't being used anymore?
> 
> I do wish that we separated the on-disk flags namespaces from the
> FS_IOC_GETFLAGS/FS_IOC_SETFLAGS namespace though...  Then adding the flag to

Use FS_IOC_{GS}ETXATTR instead?. I'ts not tied to an on-disk format.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  reply	other threads:[~2018-04-02 21:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180328181509.199870-1-ebiggers@google.com>
     [not found] ` <9ccabf5b-46ef-aa46-bdb8-6fcd96792ed0@huawei.com>
     [not found]   ` <20180330164136.GE44823@jaegeuk-macbookpro.roam.corp.google.com>
     [not found]     ` <20180330183420.GA180083@google.com>
     [not found]       ` <ec343a28-ad47-a494-ea36-c8fef72d3480@huawei.com>
2018-04-02 18:48         ` [PATCH] f2fs: reserve bits for fs-verity Eric Biggers via Linux-f2fs-devel
2018-04-02 21:49           ` Dave Chinner [this message]
2018-04-02 22:58             ` Eric Biggers via Linux-f2fs-devel

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=20180402214959.GG18129@dastard \
    --to=david@fromorbit.com \
    --cc=ebiggers@google.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=tytso@mit.edu \
    --cc=victorhsieh@google.com \
    /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).