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
> Documentation/filesystems/fsverity
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 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 track
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 keyi
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".
Note:
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: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: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: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: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: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 ext4_drop_in
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 don'
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 al
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 t
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 Wed, Jul 31, 2019 at 11:38:02AM -0700, Eric Biggers wrote:
>
> This is perhaps different from what users expect from unlink(). It's well
> known
> that unlink() just deletes the filename, not the file itself if it's still
> open
> or has other links. And unlink() by itself isn't meant for u
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 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 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 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 unnecessarily
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:
Reviewe
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 keyinfo.
> + /* Some inodes still reference this key; try to evict them. */
> + if (try_to_lock_encrypted_files(sb, mk) != 0)
> + status_flags |=
> + FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
> + }
try_to_lock_encrypted_files() c
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: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 us
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: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 polic
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 mature
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 no
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 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 r
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 h
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
> - Fil
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,
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 deadl
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 mempo
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 use
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 en
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 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 o
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 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 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 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 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&id=24ab6abb7cf6a80be44b7c72b73f0519ccaa5a97
> >
> > It's not quite rea
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 Ts'o
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 Mon, Jan 06, 2020 at 09:16:32PM -0800, Daniel Rosenberg wrote:
> changes:
> fscrypt moved to separate thread to rebase on fscrypt dev branch
> addressed feedback, plus some minor fixes
What branch was this based on? There is no fscrypt dev branch, so I
took the fscrypt master branch, and then
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 ex
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 ahash_request_fr
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 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 t
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
> resul
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
> ->dirty_inode()
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 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 to
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 th
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 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 notification desired
On Wed, Mar 25, 2020 at 02:20:57AM -0700, Christoph Hellwig wrote:
> > spin_unlock(&inode->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 & I_DIRTY_TIM
On Thu, Apr 05, 2018 at 03:21:41PM -0700, Eric Biggers wrote:
> Pass the -f option to mkfs.f2fs when it appears to support it. This is
> required by f2fs-tools v1.9 and later in order to format the filesystem
> even when an existing filesystem is detected. But earlier versions did
> not accept th
The only thing I would add to Dave's comments is that a lot of these
formal semantics are de facto, and not de jure. If you take a look at
POSIX or the Single Unix Specification, they are remarkably silent
about how fsync works.
In fact POSIX/SUS doesn't even define "fsync on a directory". In th
On Sat, Apr 14, 2018 at 08:13:28PM -0500, Vijay Chidambaram wrote:
>
> We are *not* saying an fsync on a symlink file has to result in any
> action on the original file. We understand the lack of ordering
> constraints here.
The problem is you're not being precise here. The fsync(2) system
call
On Sat, Apr 14, 2018 at 08:35:45PM -0500, Vijaychidambaram Velayudhan Pillai
wrote:
> I was one of the authors on that paper, and I didn't know until today you
> didn't like that work :) The paper did *not* suggest we support invented
> guarantees without considering the performance impact.
I had
On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>
> I don't think this is what the paper's ext3-fast does. All the paper
> says is if you have a file system where the fsync of a file persisted
> only data related to that file, it would increase performance.
> ext3-fast is the na
On Thu, Apr 19, 2018 at 01:50:20PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Allow testing f2fs using the test_dummy_encryption mount option,
> available with f2fs in kernel 4.17 and later. E.g.,
>
> gce-xfstests -c f2fs/encrypt -g auto
>
> This is the f2fs equivalent of ext4/enc
On Thu, Apr 19, 2018 at 01:50:19PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> setup_mount_opts() is supposed to prepend "-o " to the mount options,
> but it failed to do so in the case where mount options are specified in
> a config file rather than on the command line. Fix it.
>
> Sig
On Mon, Apr 30, 2018 at 03:51:34PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Hello, here's yet another round of cleanups for fscrypt. Please
> consider for v4.18. These are all patches I've sent out previously.
> The series is based on v4.17-rc3.
>
> Patches 1-12 mostly remove unnece
On Mon, May 07, 2018 at 05:22:08PM -0700, Eric Biggers wrote:
> fscrypt currently only supports AES encryption. However, many low-end
> mobile devices have older CPUs that don't have AES instructions, e.g.
> the ARMv8 Cryptography Extensions. Currently, user data on such devices
> is not encrypte
Hi, I was looking at f2fs's sources recently, and I noticed that there
is a very large number of non-static symbols which don't have a f2fs
prefix. There's well over a hundred (see attached below).
As one example, in fs/f2fs/dir.c there is:
unsigned char get_de_type(struct f2fs_dir_entry *de)
T
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 f
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 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 keyri
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 f
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 p
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 permi
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
Linux-f2fs-
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 undefine
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 filesyst
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 to
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 lookup
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 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 writ
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 h
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 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
On Fri, Aug 24, 2018 at 01:42:29PM -0400, Colin Walters wrote:
>
> While I'm not too familiar with the vfs, as far as I can
> tell from inspection of Linus' git master is that pretty much any change
> (timestamp, hardlinks) ends up
> calling notify_change() which calls the fs-specific one, and i
On Sat, Aug 25, 2018 at 10:29:26AM +0800, Gao Xiang wrote:
>
> My first question is that 'Is there any way to skip to verify pages in a bio?'
> I am thinking about
> If metadata and data page are mixed in a filesystem of such kind, they could
> submit together in a bio, but metadata could be unsu
On Sat, Aug 25, 2018 at 12:00:04PM +0800, Gao Xiang wrote:
>
> But I have some consideration than the current implementation (if it is
> suitable to discuss, thanks...)
>
> 1) Since it is the libfs-like library, I think bio-strict is too strict for
> its future fs users.
Well, it's always
On Sat, Aug 25, 2018 at 03:43:43PM +0800, Gao Xiang wrote:
> > I don't know of any plan to use fs-verity on Android's system partition or
> > to
> > replace dm-verity on the system partition. The use cases so far have been
> > verifying files on /data, like APK files.
> >
> > So I don't think yo
On Sun, Aug 19, 2018 at 11:04:06PM -0400, Theodore Ts'o wrote:
> This allows the development link libraries to be installed in
> /usr/lib, while the run-libraries are installed in /lib, which is
> required by Debian policy. This can be done via:
>
> configure --prefix=/ --libdir=/usr/lib --wi
Ping? This bug was noticed when I was repackaging f2fs-tools for
Debian. The problem is that libf2fs_format references the blkid
library, and Debian's shared library auditing tools noticed the
missing library dependency.
- Ted
On Fri, Aug 24, 2018 at 03:2
On Mon, Aug 27, 2018 at 09:57:44AM -0700, Jaegeuk Kim wrote:
>
> Thanks. I've added this and been testing with other patches for next release.
>
Are you planning on doing a new release soon?
I'm also wondering if you could give some color commentary on how
often you plan on bumping the shared ve
On Tue, Aug 28, 2018 at 12:12:02AM -0700, Jaegeuk Kim wrote:
>
> I think f2fs-tools is getting much firmer lib APIs, so don't expect frequent
> major updates on library versions, but was struggling to keep it as much as
> possible tho. I'm checking the final test results, and thus, planning to
> r
On Tue, Aug 28, 2018 at 09:59:44AM -0700, Jaegeuk Kim wrote:
>
> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
>
> I understood that, if there is no interface change but some implementation
> changes, I need to bump revision. If new interface is added, for examp
On Wed, Aug 29, 2018 at 02:04:55PM -0700, Jaegeuk Kim wrote:
> Thank you so much for kind explanation. This is really awesome especially for
> newbies like me. This gives answers to me for all my own stupid questions like
> why I need to investigate all the lib changes in order to determine bumping
On Fri, Sep 14, 2018 at 09:21:43AM -0700, Eric Biggers wrote:
> >
> > Now AIUI, Zip files have an internal header that contains e.g. the size and
> > indexes into the internal files. So if someone added random data to the end
> > of a zip file, nothing is going to end up actually reading it.
>
>
On Wed, Sep 12, 2018 at 08:57:16AM +0900, Wang Shilong wrote:
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index a7074115d6f6..f81102bd3203 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -339,19 +339,14 @@ static int ext4_ioctl_setproject(struct file *filp,
> __u32 projid)
>
On Sun, Sep 16, 2018 at 04:02:52AM +, Wang Shilong wrote:
>
>
> > 在 2018年9月16日，上午11:55，Theodore Y. Ts'o 写道：
> >
> > On Wed, Sep 12, 2018 at 08:57:16AM +0900, Wang Shilong wrote:
> >> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> >> index
On Wed, Sep 12, 2018 at 11:04:35PM +0800, cgxu519 wrote:
> On 08/31/2018 10:33 PM, Chengguang Xu wrote:
> > default_acl and acl of newly created inode will be initiated
> > as ACL_NOT_CACHED in vfs function inode_init_always() and later
> > will be updated by calling xxx_init_acl() in specific file
1 - 100 of 128 matches
Mail list logo
