On Thu, Dec 17, 2020 at 08:51:14PM +, Satya Tangirala wrote:
> On Thu, Dec 17, 2020 at 01:08:49PM -0500, Theodore Y. Ts'o wrote:
> > On Thu, Dec 17, 2020 at 03:04:32PM +, Satya Tangirala wrote:
> > > This patch series adds support for metadata encryption to F2FS usin
On Thu, Dec 17, 2020 at 03:04:32PM +, Satya Tangirala wrote:
> This patch series adds support for metadata encryption to F2FS using
> blk-crypto.
Is there a companion patch series needed so that f2fstools can
check/repair a file system with metadata encryption enabled?
On Tue, Nov 17, 2020 at 02:07:06PM +, Satya Tangirala wrote:
> From: Eric Biggers
>
> Wire up ext4 with fscrypt direct I/O support. Direct I/O with fscrypt is
> only supported through blk-crypto (i.e. CONFIG_BLK_INLINE_ENCRYPTION must
> have been enabled, the 'inlinecrypt' mount option must
On Mon, Nov 30, 2020 at 10:39:08AM -0800, Eric Biggers wrote:
> Then there is the issue of ordering and how different operations would
> interact
> with each other. This proposal would require the ability to open() a regular
> file that doesn't have its encryption key available, and read and
On Tue, Nov 17, 2020 at 09:04:11AM -0800, Jaegeuk Kim wrote:
>
> I'd like to pick this patch series in f2fs/dev for -next, so please let me
> know
> if you have any concern.
No concern for me as far as ext4 is concerned, thanks!
- Ted
On Tue, Nov 17, 2020 at 04:03:13AM +, Daniel Rosenberg wrote:
> This adds a function to set dentry operations at lookup time that will
> work for both encrypted filenames and casefolded filenames.
>
> A filesystem that supports both features simultaneously can use this
> function during
What is the expected use case for Direct I/O using fscrypt? This
isn't a problem which is unique to fscrypt, but one of the really
unfortunate aspects of the DIO interface is the silent fallback to
buffered I/O. We've lived with this because DIO goes back decades,
and the original use case was
On Tue, Nov 17, 2020 at 04:03:14AM +, Daniel Rosenberg wrote:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate as appropriate.
>
> Most
On Mon, Jun 01, 2020 at 02:49:51PM -0600, Andreas Dilger wrote:
> On Jun 1, 2020, at 2:05 PM, Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > If the dentry name passed to ->d_compare() fits in dentry::d_iname, then
> > it may be concurrently modified by a rename. This can cause
On Mon, May 18, 2020 at 08:02:05PM -0700, Eric Biggers wrote:
>
> Thanks, I'll add that. I assume you meant "Reviewed-by"?
Yes, thanks.
Reviewed-by: Theodore Ts'o
- Ted
___
Linux-f2fs-devel mailing list
On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
> an encryption format which uses one key per policy and
On Tue, May 12, 2020 at 04:32:51PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Since v1 encryption policies are deprecated, make test_dummy_encryption
> test v2 policies by default.
>
> Note that this causes ext4/023 and ext4/028 to start failing due to
> known bugs in those tests (see
On Tue, May 12, 2020 at 04:32:50PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> v1 encryption policies are deprecated in favor of v2, and some new
> features (e.g. encryption+casefolding) are only being added for v2.
>
> Therefore, the "test_dummy_encryption" mount option (which is used
On Tue, May 12, 2020 at 04:32:49PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Currently, the test_dummy_encryption mount option (which is used for
> encryption I/O testing with xfstests) uses v1 encryption policies, and
> it relies on userspace inserting a test key into the session
On Tue, May 12, 2020 at 04:32:48PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> is missing include guards. Add them.
>
> This is needed to allow declaring a function in that
> takes a substring_t parameter.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Theodore Ts'o
On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
>
> After a lot of output on a damaged filesystem (SD card copied to an image)
> fsck.f2fs dies with:
>
> - File name : mkfs.ext3.dpkg-new
> - File size : 6 (bytes)
>
> Program received signal SIGSEGV, Segmentation
On Wed, Mar 25, 2020 at 02:20:57AM -0700, Christoph Hellwig wrote:
> > spin_unlock(>i_lock);
> >
> > - if (dirty & I_DIRTY_TIME)
> > - mark_inode_dirty_sync(inode);
> > + /* This was a lazytime expiration; we need to tell the file system */
> > + if (dirty &
On Tue, Mar 24, 2020 at 01:37:59AM -0700, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 01:58:38PM -0400, Theodore Y. Ts'o wrote:
> > Christoph, Dave --- does this give you the notification that you were
> > looking such that XFS could get the notif
Christoph, Dave --- does this give you the notification that you were
looking such that XFS could get the notification desired that it was
the timestamps need to be written back?
- Ted
On Thu, Mar 19, 2020 at 10:52:55PM -0400, Theodore Ts'o wrote:
> Use the flag
On Thu, Mar 12, 2020 at 07:34:45AM -0700, Christoph Hellwig wrote:
> I haven't seen the original mail this replies to, but if we could
> get the lazytime expirty by some other means (e.g. an explicit
> callback), XFS could opt out of all the VFS inode tracking again,
> which would simplify a few
On Sat, Mar 14, 2020 at 01:50:49PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add an ioctl FS_IOC_GET_ENCRYPTION_NONCE which retrieves the nonce from
> an encrypted file or directory. The nonce is the 16-byte random value
> stored in the inode's encryption xattr. It is normally used
On Sat, Mar 14, 2020 at 01:50:50PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> This new ioctl retrieves a file's encryption nonce, which is useful for
> testing. See the corresponding fs/crypto/ patch for more details.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Theodore Ts'o
On Tue, Mar 10, 2020 at 08:20:09PM -0700, Eric Biggers wrote:
> Thanks Ted! This fixes the fscrypt test failure.
>
> However, are you sure this works correctly on all filesystems? I'm not sure
> about XFS. XFS only implements ->dirty_inode(), not ->write_inode(), and in
> its
>
On Thu, Jan 23, 2020 at 08:12:34PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Since ->d_compare() and ->d_hash() can be called in RCU-walk mode,
> ->d_parent and ->d_inode can be concurrently modified, and in
> particular, ->d_inode may be changed to NULL. For ext4_d_hash() this
>
On Fri, Jan 17, 2020 at 12:12:46AM -0800, Christoph Hellwig wrote:
> On Thu, Jan 16, 2020 at 11:20:08AM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Reserve flags for the hardware-wrapped keys feature which is being
> > worked on [1]. FSCRYPT_POLICY_FLAG_HW_WRAPPED_KEY will denote
On Mon, Jan 06, 2020 at 12:54:10PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> When it builds the first level of the Merkle tree, FS_IOC_ENABLE_VERITY
> sequentially reads each page of the file using read_mapping_page().
> This works fine if the file's data is already in pagecache, which
On Tue, Dec 31, 2019 at 11:55:45AM -0600, Eric Biggers wrote:
> From: Eric Biggers
>
> When initializing an fs-verity hash algorithm, also initialize a mempool
> that contains a single preallocated hash request object. Then replace
> the direct calls to ahash_request_alloc() and
On Mon, Jan 06, 2020 at 12:55:33PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> When fs-verity verifies data pages, currently it reads each Merkle tree
> page synchronously using read_mapping_page().
>
> Therefore, when the Merkle tree pages aren't already cached, fs-verity
> causes an
On Mon, Dec 02, 2019 at 09:10:45PM -0800, Daniel Rosenberg wrote:
> @@ -228,6 +229,13 @@ static inline int dentry_string_cmp(const unsigned char
> *cs, const unsigned char
>
> #endif
>
> +bool needs_casefold(const struct inode *dir)
> +{
> + return IS_CASEFOLDED(dir) &&
> +
On Wed, Dec 18, 2019 at 11:23:31AM -0800, Darrick J. Wong wrote:
> *OH*, because we're stuffing the value in ret2, not ret. Ok, that makes
> more sense. Er, I guess I don't mind pushing via iomap tree, but could
> we get some acks from Ted and any of the ceph maintainers?
Acked-by: Theodore
On Sat, Nov 16, 2019 at 12:53:19AM +0200, Jarkko Sakkinen wrote:
> > I'm working on an xfstest for this:
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git/commit/?h=fscrypt-provisioning=24ab6abb7cf6a80be44b7c72b73f0519ccaa5a97
> >
> > It's not quite
On Tue, Nov 05, 2019 at 08:05:19PM -0800, Eric Biggers wrote:
> If we really wanted to optimize fscrypt_get_encryption_info(), I think we
> probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather
> take advantage of the fact that fscrypt_has_permitted_context() already ran.
On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote:
> @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy
> *policy_u,
> return false;
> }
>
> + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) &&
> +
On Thu, Oct 24, 2019 at 02:54:37PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> IV_INO_LBLK_64 encryption policies have special requirements from the
> filesystem beyond those of the existing encryption policies:
>
> - Inode numbers must never change, even if the filesystem is resized.
>
On Mon, Nov 04, 2019 at 09:46:14PM -0500, Valdis Kletnieks wrote:
> Four filesystems have their own defines for this. Move it
> into errno.h so it's defined in just one place.
>
> Signed-off-by: Valdis Kletnieks
Acked-by: Theodore Ts'o
- Ted
On Sat, Nov 02, 2019 at 03:10:17PM -0700, Guenter Roeck wrote:
>
> This change is now in our code base:
>
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/5c5b06fded399013b9cce3d504c3d968ee84ab8b
>
> If the revert has not made it upstream, I would suggest to hold it
On Wed, Oct 30, 2019 at 09:07:33PM -0400, Valdis Kletnieks wrote:
> Three questions: (a) ACK/NAK on this patch, (b) should it be all in one
> patch, or one to add to errno.h and 6 patches for 6 filesystems?), and
> (c) if one patch, who gets to shepherd it through?
Acked-by: Theodore Ts'o
On Thu, Oct 31, 2019 at 10:57:13AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 28, 2019 at 12:20:26AM -0700, Satya Tangirala wrote:
> > We introduce blk-crypto, which manages programming keyslots for struct
> > bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
> > the
On Wed, Oct 30, 2019 at 02:51:38PM -0700, Eric Biggers wrote:
> From: Douglas Anderson
>
> This reverts commit 0642ea2409f3 ("ext4 crypto: fix to check feature
> status before get policy").
>
> The commit made a clear and documented ABI change that is not backward
> compatible. There exists
On Wed, Oct 30, 2019 at 11:50:37PM +0800, Gao Xiang wrote:
>
> So I'm curious about the original issue in commit 740432f83560
> ("f2fs: handle failed bio allocation"). Since f2fs manages multiple write
> bios with its internal fio but it seems the commit is not helpful to
> resolve potential
On Wed, Oct 30, 2019 at 06:43:45PM +0800, Gao Xiang wrote:
> > You're right, in low memory scenario, allocation with bioset will be
> > faster, as
> > you mentioned offline, maybe we can add/use a priviate bioset like btrfs did
> > rather than using global one, however, we'd better check how
On Wed, Oct 23, 2019 at 02:27:18AM -0700, Christoph Hellwig wrote:
> On Tue, Oct 22, 2019 at 09:30:01AM -0400, Theodore Y. Ts'o wrote:
> > If and when we actually get inline crypto support for server-class
> > systems, hopefully they will support 128-bit DUN's, and/or the
On Mon, Oct 21, 2019 at 04:03:54PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> INLINE_CRYPT_OPTIMIZED encryption policies have special requirements
> from the filesystem:
>
> - Inode numbers must never change, even if the filesystem is resized
> - Inode numbers must be <= 32 bits
> -
On Mon, Oct 21, 2019 at 11:00:04PM -0700, Eric Biggers wrote:
> That won't work because we need consecutive file blocks to have consecutive
> IVs
> as often as possible. The crypto support in the UFS and EMMC standards takes
> only a single 64-bit "data unit number" (DUN) per request, which the
On Mon, Sep 23, 2019 at 12:10:42PM +0200, Jan Kara wrote:
> On Wed 11-09-19 11:45:16, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > This is similar to 942491c9e6d6 ("xfs: fix AIM7 regression")
> > Apparently our current rwsem code doesn't like doing the trylock, then
> > lock for
On Tue, Aug 27, 2019 at 05:33:33PM +0900, boojin.kim wrote:
>
> Dear Satya.
> Keyslot manager is a good solution for ICE. And probably no issue for FMP.
> But, I think it's complicated for FMP because FMP doesn't need
> any keyslot control.
Hi Boojin,
I think the important thing to realize here
On Tue, Aug 20, 2019 at 10:35:29AM +0530, Chandan Rajendra wrote:
> Looks like F2FS requires a lot more flexiblity than what can be offered by
> read callbacks i.e.
>
> 1. F2FS wants to make use of its own workqueue for decryption, verity and
>decompression.
> 2. F2FS' decompression code is
On Tue, Aug 20, 2019 at 01:12:36PM +0800, Gao Xiang wrote:
> Add a word, I have some little concern about post read procession order
> a bit as I mentioned before, because I'd like to move common EROFS
> decompression code out in the future as well for other fses to use
> after we think it's
On Mon, Aug 05, 2019 at 09:25:21AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Update the fscrypt documentation file to catch up to all the latest
> changes, including the new ioctls to manage master encryption keys in
> the filesystem-level keyring and the support for v2 encryption
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
>
On Mon, Aug 05, 2019 at 09:25:16AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add a root-only variant of the FS_IOC_REMOVE_ENCRYPTION_KEY ioctl which
> removes all users' claims of the key, not just the current user's claim.
> I.e., it always removes the key itself, no matter how many
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
On Mon, Aug 05, 2019 at 09:25:08AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In preparation for introducing v2 encryption policies which will find
> and derive encryption keys differently from the current v1 encryption
> policies, move the v1 policy-specific key setup code from
On Mon, Aug 05, 2019 at 09:25:09AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Rename keyinfo.c to keysetup.c since this better describes what the file
> does (sets up the key), and it matches the new file keysetup_v1.c.
>
> Signed-off-by: Eric Biggers
Looks good, you can add:
On Mon, Aug 05, 2019 at 09:25:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Do some more refactoring of the key setup code, in preparation for
> introducing a filesystem-level keyring and v2 encryption policies:
>
> - Now that ci_inode exists, don't pass around the inode
On Mon, Aug 05, 2019 at 09:25:06AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In preparation for introducing a filesystem-level keyring which will
> contain fscrypt master keys, rename the existing 'struct
> fscrypt_master_key' to 'struct fscrypt_direct_key'. This is the
> structure in
On Thu, Aug 01, 2019 at 09:38:27PM -0700, Eric Biggers wrote:
>
> Here's a slightly updated version (I missed removing some stale text):
Apologies for the delaying in getting back. Thanks, this looks great.
- Ted
>
> Removing keys
> -
On Wed, Jul 31, 2019 at 06:11:40PM -0700, Eric Biggers wrote:
>
> Well, it's either
>
> 1a. Remove the user's handle.
> OR
> 1b. Remove all users' handles. (FSCRYPT_REMOVE_KEY_FLAG_ALL_USERS)
>
> Then
>
> 2. If no handles remain, try to evict all inodes that use the key.
>
> By "purge
On Fri, Jul 26, 2019 at 03:41:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Wire up the new ioctls for adding and removing fscrypt keys to/from the
> filesystem, and the new ioctl for retrieving v2 encryption policies.
>
> FS_IOC_REMOVE_ENCRYPTION_KEY also required making UBIFS use
>
On Mon, Jul 29, 2019 at 12:46:45PM -0700, Eric Biggers wrote:
> > For that matter, we could just add a new ioctl which returns the file
> > system's keyring id. That way an application program won't have to
> > try to figure out what a file's underlying sb->s_id happens to be.
> > (Especially if
On Fri, Jul 26, 2019 at 03:41:41PM -0700, Eric Biggers wrote:
> +- The kernel cannot magically wipe copies of the master key(s) that
> + userspace might have as well. Therefore, userspace must wipe all
> + copies of the master key(s) it makes as well. Naturally, the same
> + also applies to
On Fri, Jul 26, 2019 at 03:41:37PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> By looking up the master keys in a filesystem-level keyring rather than
> in the calling processes' key hierarchy, it becomes possible for a user
> to set an encryption policy which refers to some key they
On Fri, Jul 26, 2019 at 03:41:38PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Wire up the new ioctls for adding and removing fscrypt keys to/from the
> filesystem, and the new ioctl for retrieving v2 encryption policies.
>
> FS_IOC_REMOVE_ENCRYPTION_KEY also required making
On Fri, Jul 26, 2019 at 03:41:36PM -0700, Eric Biggers wrote:
> diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
> index 56e085c2ed8c6..307533d4d7c51 100644
> --- a/fs/crypto/keyring.c
> +++ b/fs/crypto/keyring.c
> + if (mk->mk_users->keys.nr_leaves_on_tree != 0) {
> +
On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user
> *_uarg)
> if (!capable(CAP_SYS_ADMIN))
> goto out_wipe_secret;
>
> + if (arg.key_spec.type != FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR)
On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> deriving additional key material from the fscrypt master keys for v2
> encryption policies. HKDF is a key derivation function built on
On Fri, Jul 26, 2019 at 03:41:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
> specified by 'struct fscrypt_key_specifier' (the same way a key is
> specified for the other fscrypt key management ioctls), it returns
On Fri, Jul 26, 2019 at 03:41:32PM -0700, Eric Biggers wrote:
> + fscrypt_warn(NULL,
> + "%s: %zu inodes still busy after removing key with
> description %*phN, including ino %lu (%s)",
nit: s/inodes/inode(s)/
> +
> +/*
> + * Try to remove an fscrypt master encryption key.
On Fri, Jul 26, 2019 at 03:41:31PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
> encryption key to the filesystem's fscrypt keyring ->s_master_keys,
> making any files encrypted with that key appear "unlocked".
On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In preparation for introducing v2 encryption policies which will find
> and derive encryption keys differently from the current v1 encryption
> policies, refactor the v1 policy-specific key setup code from
On Fri, Jul 26, 2019 at 03:41:29PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add an inode back-pointer to 'struct fscrypt_info', such that
> inode->i_crypt_info->ci_inode == inode.
>
> This will be useful for:
>
> 1. Evicting the inodes when a fscrypt key is removed, since we'll
On Fri, Jul 26, 2019 at 03:41:26PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> More fscrypt definitions are being added, and we shouldn't use a
> disproportionate amount of space in for fscrypt stuff.
> So move the fscrypt definitions to a new header .
>
> For source compatibility with
On Mon, Jul 22, 2019 at 09:50:54AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add a function for filesystems to call to implement the
> FS_IOC_ENABLE_VERITY ioctl. This ioctl enables fs-verity on a file.
>
> See the "FS_IOC_ENABLE_VERITY" section of
>
On Tue, Feb 12, 2019 at 08:06:52AM -0500, Mimi Zohar wrote:
> Yes, I understand that your primary goal hasn't changed. Linus was
> suggesting "the interface be made idempotent" to support "filesystems
> that don't actually have any long-term storage model for the merkle
> tree. IOW, you could do
On Tue, Feb 12, 2019 at 09:44:39AM -0500, Mimi Zohar wrote:
> Ted, one of the problems with IMA is that the file hash/signature
> verification is at file open. It isn't aware when files are brought
> in from cache. Does fs-verity re-verify blocks as they're restored
> from cache? For some use
On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote:
> For which files will the Merkle tree be created? Is this for all
> files on a per file system basis? Or is there some sort of "flag" or
> policy? The original design was based on an ioctl enabling/disabling
> a flag. In this new
On Sat, Feb 09, 2019 at 12:38:05PM -0800, Linus Torvalds wrote:
>
> In particular, may I suggest that the interface be made idempotent,
> so that you can do the merkle tree operation several times with the
> same offset/length arguments, and if the merkle tree has already been
> calculated, you
After doing a lot of thinking and conferring with the other fs-verity
developers, our current thinking is to simply move the Merkle tree
creation into the kernel. The upside of doing this is it completely
bypasses all of the complaints about how to transfer the Merkle tree
from userspace to the
On Fri, Jan 25, 2019 at 01:35:05PM +1300, Linus Torvalds wrote:
> But that's the whole hiding thing. Why do you feel you need to do
> that? Why not just leave it alone, and leave it visible, and say "hey,
> the merkle data for file X comes from here".
There are a number of downsides:
*) It's
On Fri, Jan 25, 2019 at 10:40:31AM +1300, Linus Torvalds wrote:
>
> I _assume_ (but it's exactly that - just an assumption) this whole
> design decision comes from basically having a transport layer that is
> entirely unaware of the merle data, so the data is brought in some
> entirely
On Thu, Jan 24, 2019 at 10:29:50AM -0800, Eric Biggers wrote:
>
> Hi Ted, that sounds good to me. I assume you know how to get that set up?
> Also, should I go ahead and send a patch that adds myself to the MAINTAINERS
> file?
I have the request to the git.kernel.org folks and the edits to the
On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
>
> Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
> made it into the fscrypt tree and hence never made it into linux-next.
>
Apologies for the delay in getting responding; I've been on vacation
last week.
On Tue, Jan 15, 2019 at 10:41:01AM +1100, Dave Chinner wrote:
> > int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg);
> >
> > struct fsverity_arg {
> >int fsv_donor_fd;
> >u64 fsv_offset;
>
The following approach is based in Darrick's suggestion:
int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg);
struct fsverity_arg {
int fsv_donor_fd;
u64 fsv_offset;
u64 fsv_size;
};
fsv_offset and fsz_size must be a multiple of the file system block
size. If the
On Sat, Dec 22, 2018 at 08:10:07PM -0800, Matthew Wilcox wrote:
> Pretty much every file format has the ability to put arbitrary blocks
> of information into a file somewhere the tools which don't know about
> it will skip it. For example, ZIP "includes an extra field facility
> within file
On Sat, Dec 22, 2018 at 02:47:22PM -0800, Linus Torvalds wrote:
> So I want to understand why this was made a filesystem operation in
> the first place. What's fs-specific about this implementation?
These are the things which are fs-specific.
*) We have to splice into the file system's readpage
On Fri, Dec 21, 2018 at 11:13:07AM -0800, Linus Torvalds wrote:
>
> I do agree that your particular model is pretty damn broken in lots of ways.
>
> Why is it filesystem specific? If the whole point is that the file
> itself has its own verification data (which I like), then I don't see
> why
On Fri, Dec 21, 2018 at 07:53:54AM -0800, Matthew Wilcox wrote:
> In contrast to "we'll just fix it up later" (which usually applies
> to in-kernel interfaces), we have a policy of not breaking userspace,
> so accepting this interface means setting it in stone. We should get
> it right.
I'm not
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true. Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of
On Thu, Dec 20, 2018 at 08:35:52AM +1100, Dave Chinner wrote:
>
> The file has to be written before it has been protected, which means
> it may very well have user space allocated beyond EOF before the
> merkle tree needs to be written.
Sure, and every file system knows how to truncate a file.
On Wed, Dec 19, 2018 at 01:19:53PM +1100, Dave Chinner wrote:
> Putting metadata in user files beyond EOF doesn't work with XFS's
> post-EOF speculative allocation algorithms.
>
> i.e. Filesystem design/algorithms often assume that the region
> beyond EOF in user files is a write-only region.
On Mon, Dec 17, 2018 at 12:00:39PM -0800, Darrick J. Wong wrote:
> FWIW, if I were (hypothetically) working on an xfs implementation, I
> likely would have settled on passing a reference to a merkle tree
> through a (fd, length) pair, because that allows us plenty of options
> on the back end:
>
On Thu, Dec 13, 2018 at 12:22:49PM -0800, Christoph Hellwig wrote:
> On Wed, Dec 12, 2018 at 12:26:10PM -0800, Eric Biggers wrote:
> > > As this apparently got merged despite no proper reviews from VFS
> > > level persons:
> >
> > fs-verity has been out for review since August, and Cc'ed to all
On Tue, Dec 11, 2018 at 06:42:22PM -0800, Eric Biggers wrote:
>
> Either works, but I slightly prefer my version since it minimizes the overhead
> on non-verity files when the kconfig option is enabled: it's just an i_flags
> check, rather than a function call plus an i_flags check. The same
The fscrypt.git tree has been updated with for the problem. Apologies
for not testing the !CONFIG_FS_VERITY case.
- Ted
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
On Tue, Dec 11, 2018 at 03:15:53PM +0100, Krzysztof Kozlowski wrote:
> Hi,
>
> Bisect from today's next pointed me to:
> commit 4de97efb578a094e8fbf279522d41eb9ece1e3e0
> Author: Chandan Rajendra
> Date: Sat Dec 8 12:21:43 2018 +0530
> fsverity: Move verity status check to
Chandan,
Thanks! I've applied this patch series to the fscrypt git tree.
- Ted
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
On Mon, Nov 19, 2018 at 10:53:22AM +0530, Chandan Rajendra wrote:
> This commit now uses IS_VERITY() macro to check if fsverity is
> enabled on an inode.
>
> Signed-off-by: Chandan Rajendra
This patch causes a massive number of fsverity tests. I suspect it's
due to a mismatch between the
On Sun, Nov 25, 2018 at 11:00:38PM -0500, Theodore Y. Ts'o wrote:
>
> It might be that the simplest way to solve things is to merge the f2fs
> dev branch up to 79c66e75720c. This will have the net effect of
> including the five patches listed above onto the fscrypt git tree. So
>
On Mon, Nov 19, 2018 at 01:23:32PM -0800, Jaegeuk Kim wrote:
> Hi Chandan,
>
> Let me try to queue and test this patch separately from the patch-set in order
> to avoid merge conflicts. So, I think IS_ENCRYPTED should be merged in
> f2fs/ext4
> branches, and the others can be applied to fscrypt
1 - 100 of 122 matches
Mail list logo
