From: Eric Biggers <ebiggers@kernel.org> To: Ritesh Harjani <ritesh.list@gmail.com> Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Lukas Czerner <lczerner@redhat.com>, Jeff Layton <jlayton@kernel.org>, Theodore Ts'o <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org> Subject: Re: [PATCH v2 5/7] ext4: fix up test_dummy_encryption handling for new mount API Date: Fri, 13 May 2022 15:24:59 -0700 [thread overview] Message-ID: <Yn7au5Pckn5T0iTm@sol.localdomain> (raw) In-Reply-To: <20220513105853.v7iw2mbi3ycg2rqg@riteshh-domain> On Fri, May 13, 2022 at 04:28:53PM +0530, Ritesh Harjani wrote: > On 22/05/11 06:03PM, Eric Biggers wrote: > > On Wed, May 11, 2022 at 11:24:33PM +0530, Ritesh Harjani wrote: > > > On 22/05/09 04:40PM, Eric Biggers wrote: > > > > A couple corrections I'll include in the next version: > > > > > > Need few clarifications. Could you please help explain what am I missing here? > > > > > > > > > > > On Sat, Apr 30, 2022 at 10:08:55PM -0700, Eric Biggers wrote: > > > > > + if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE) { > > > > > + if (fscrypt_dummy_policies_equal(&sbi->s_dummy_enc_policy, > > > > > + &ctx->dummy_enc_policy)) > > > > > + return 0; > > > > > ext4_msg(NULL, KERN_WARNING, > > > > > - "Can't set test_dummy_encryption on remount"); > > > > > + "Can't set or change test_dummy_encryption on remount"); > > > > > return -EINVAL; > > > > > } > > > > > > > > I think this needs to be 'fc->purpose == FS_CONTEXT_FOR_RECONFIGURE || > > > > fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy)', since ext4 can parse > > > > mount options from both s_mount_opts and the regular mount options. > > > > > > Sorry, I am missing something here. Could you please help me understand why > > > do we need the other OR case which you mentioned above i.e. > > > "|| fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy)" > > > > > > So maybe to put it this way, when will it be the case where > > > fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy) is true and it is not a > > > FS_CONTEXT_FOR_RECONFIGURE case? > > > > The case where test_dummy_encryption is present in both the mount options stored > > in the superblock and in the regular mount options. See how __ext4_fill_super() > > parses and applies each source of options separately. > > Ok, thanks for clarifying. So this says that > 1. in case of mount; if test_dummy_encryption is already set with some policy in > the disk superblock and if the user is trying to change the mount option in > options string, then that is not allowed. > 2. Similarly if while remounting we try to change the mount option from the > previous mount option, then again this is not allowed. > Yes. I assume that the expected behavior of the on-disk mount options is the same as if they were prepended to the user-specified mount options. So we simply aren't allowing conflicting test_dummy_encryption options in the mount options, regardless of where the mount options came from. > > > > > +static void ext4_apply_test_dummy_encryption(struct ext4_fs_context *ctx, > > > > > + struct super_block *sb) > > > > > +{ > > > > > + if (!fscrypt_is_dummy_policy_set(&ctx->dummy_enc_policy)) > > > > > + return; > > > > > > > > To handle remounts correctly, this needs to be > > > > '!fscrypt_is_dummy_policy_set(&ctx->dummy_enc_policy) || > > > > fscrypt_is_dummy_policy_set(&EXT4_SB(sb)->s_dummy_enc_policy)'. > > > > > > Why? > > > Isn't it true that in remount we should update EXT4_SB(sb)->s_dummy_enc_policy > > > only when ctx->dummy_enc_policy is set. If EXT4_SB(sb)->s_dummy_enc_policy is > > > already set and ctx->dummy_enc_policy is not set, that means it's a remount case with no mount > > > opts in which case ext4 should continue to have the same value of EXT4_SB(sb)->s_dummy_enc_policy? > > > > struct fscrypt_dummy_policy includes dynamically allocated memory, so > > overwriting it without first freeing it would be a memory leak. > > Ok yes. Since this is dynamic memory allocation. Hence > I see that ext4_apply_test_dummy_encryption() can be called from > parse_apply_sb_mount_options(), __ext4_fill_super() and __ext4_remount(). > > Case 1: when this mount option is set in superblock > 1. So in parse_apply_sb_mount_options(), this mount option will get set the > first time if it is also set in superblock field. > > 2. So if we also have a same mount option set in regular mount, > or during remount both will have sbi->s_dummy_enc_policy already set (from > step 1 above), so we should do nothing here. > > Case 2: when this mount option is passed as regular mount > 1. parse_apply_sb_mount_options() won't set this. > 2. __ext4_fill_super() will set this mount option in sbi and hence __ext4_remount > should not set this again. > > And as I see you are cleverly setting memset &ctx->dummy_enc_policy to 0 > in case where we applied the parsed mount option to sbi. So that the actual > policy doesn't get free when you call __ext4_fc_free() after ext4_apply_options() > in parse_apply_sb_mount_options(). And in other cases where this mount option was > not applied to sbi mount opt, in that case we anyway want this policy to get > free. > > This somehow looks very confusing to me. But I guess with parse, check and apply > mount APIs and with mount options in superblock, regular and remount path, this > couldn't be avoided (although I am no expert in this area). > > Thanks for explaining. I hope I got this right ;) That's all correct. I think you're overthinking it a bit. The important thing is that if the dummy policy is being set, we must move it into the ext4_sb_info. Zeroing the old location is just part of transferring ownership of memory in C. If a dummy policy was already set, we don't support changing it, and we've checked that any "new" value is consistent with it, so we don't do anything. - Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org> To: Ritesh Harjani <ritesh.list@gmail.com> Cc: Theodore Ts'o <tytso@mit.edu>, Jeff Layton <jlayton@kernel.org>, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>, Lukas Czerner <lczerner@redhat.com>, linux-ext4@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v2 5/7] ext4: fix up test_dummy_encryption handling for new mount API Date: Fri, 13 May 2022 15:24:59 -0700 [thread overview] Message-ID: <Yn7au5Pckn5T0iTm@sol.localdomain> (raw) In-Reply-To: <20220513105853.v7iw2mbi3ycg2rqg@riteshh-domain> On Fri, May 13, 2022 at 04:28:53PM +0530, Ritesh Harjani wrote: > On 22/05/11 06:03PM, Eric Biggers wrote: > > On Wed, May 11, 2022 at 11:24:33PM +0530, Ritesh Harjani wrote: > > > On 22/05/09 04:40PM, Eric Biggers wrote: > > > > A couple corrections I'll include in the next version: > > > > > > Need few clarifications. Could you please help explain what am I missing here? > > > > > > > > > > > On Sat, Apr 30, 2022 at 10:08:55PM -0700, Eric Biggers wrote: > > > > > + if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE) { > > > > > + if (fscrypt_dummy_policies_equal(&sbi->s_dummy_enc_policy, > > > > > + &ctx->dummy_enc_policy)) > > > > > + return 0; > > > > > ext4_msg(NULL, KERN_WARNING, > > > > > - "Can't set test_dummy_encryption on remount"); > > > > > + "Can't set or change test_dummy_encryption on remount"); > > > > > return -EINVAL; > > > > > } > > > > > > > > I think this needs to be 'fc->purpose == FS_CONTEXT_FOR_RECONFIGURE || > > > > fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy)', since ext4 can parse > > > > mount options from both s_mount_opts and the regular mount options. > > > > > > Sorry, I am missing something here. Could you please help me understand why > > > do we need the other OR case which you mentioned above i.e. > > > "|| fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy)" > > > > > > So maybe to put it this way, when will it be the case where > > > fscrypt_is_dummy_policy_set(&sbi->s_dummy_enc_policy) is true and it is not a > > > FS_CONTEXT_FOR_RECONFIGURE case? > > > > The case where test_dummy_encryption is present in both the mount options stored > > in the superblock and in the regular mount options. See how __ext4_fill_super() > > parses and applies each source of options separately. > > Ok, thanks for clarifying. So this says that > 1. in case of mount; if test_dummy_encryption is already set with some policy in > the disk superblock and if the user is trying to change the mount option in > options string, then that is not allowed. > 2. Similarly if while remounting we try to change the mount option from the > previous mount option, then again this is not allowed. > Yes. I assume that the expected behavior of the on-disk mount options is the same as if they were prepended to the user-specified mount options. So we simply aren't allowing conflicting test_dummy_encryption options in the mount options, regardless of where the mount options came from. > > > > > +static void ext4_apply_test_dummy_encryption(struct ext4_fs_context *ctx, > > > > > + struct super_block *sb) > > > > > +{ > > > > > + if (!fscrypt_is_dummy_policy_set(&ctx->dummy_enc_policy)) > > > > > + return; > > > > > > > > To handle remounts correctly, this needs to be > > > > '!fscrypt_is_dummy_policy_set(&ctx->dummy_enc_policy) || > > > > fscrypt_is_dummy_policy_set(&EXT4_SB(sb)->s_dummy_enc_policy)'. > > > > > > Why? > > > Isn't it true that in remount we should update EXT4_SB(sb)->s_dummy_enc_policy > > > only when ctx->dummy_enc_policy is set. If EXT4_SB(sb)->s_dummy_enc_policy is > > > already set and ctx->dummy_enc_policy is not set, that means it's a remount case with no mount > > > opts in which case ext4 should continue to have the same value of EXT4_SB(sb)->s_dummy_enc_policy? > > > > struct fscrypt_dummy_policy includes dynamically allocated memory, so > > overwriting it without first freeing it would be a memory leak. > > Ok yes. Since this is dynamic memory allocation. Hence > I see that ext4_apply_test_dummy_encryption() can be called from > parse_apply_sb_mount_options(), __ext4_fill_super() and __ext4_remount(). > > Case 1: when this mount option is set in superblock > 1. So in parse_apply_sb_mount_options(), this mount option will get set the > first time if it is also set in superblock field. > > 2. So if we also have a same mount option set in regular mount, > or during remount both will have sbi->s_dummy_enc_policy already set (from > step 1 above), so we should do nothing here. > > Case 2: when this mount option is passed as regular mount > 1. parse_apply_sb_mount_options() won't set this. > 2. __ext4_fill_super() will set this mount option in sbi and hence __ext4_remount > should not set this again. > > And as I see you are cleverly setting memset &ctx->dummy_enc_policy to 0 > in case where we applied the parsed mount option to sbi. So that the actual > policy doesn't get free when you call __ext4_fc_free() after ext4_apply_options() > in parse_apply_sb_mount_options(). And in other cases where this mount option was > not applied to sbi mount opt, in that case we anyway want this policy to get > free. > > This somehow looks very confusing to me. But I guess with parse, check and apply > mount APIs and with mount options in superblock, regular and remount path, this > couldn't be avoided (although I am no expert in this area). > > Thanks for explaining. I hope I got this right ;) That's all correct. I think you're overthinking it a bit. The important thing is that if the dummy policy is being set, we must move it into the ext4_sb_info. Zeroing the old location is just part of transferring ownership of memory in C. If a dummy policy was already set, we don't support changing it, and we've checked that any "new" value is consistent with it, so we don't do anything. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2022-05-13 22:25 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-01 5:08 [PATCH v2 0/7] test_dummy_encryption fixes and cleanups Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 1/7] ext4: only allow test_dummy_encryption when supported Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-11 12:50 ` Ritesh Harjani 2022-05-11 12:50 ` [f2fs-dev] " Ritesh Harjani 2022-05-11 17:18 ` Eric Biggers 2022-05-11 17:18 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 2/7] f2fs: reject test_dummy_encryption when !CONFIG_FS_ENCRYPTION Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 3/7] fscrypt: factor out fscrypt_policy_to_key_spec() Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 4/7] fscrypt: add new helper functions for test_dummy_encryption Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 5/7] ext4: fix up test_dummy_encryption handling for new mount API Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-09 23:40 ` Eric Biggers 2022-05-09 23:40 ` Eric Biggers 2022-05-11 17:54 ` [f2fs-dev] " Ritesh Harjani 2022-05-11 17:54 ` Ritesh Harjani 2022-05-11 18:03 ` Eric Biggers 2022-05-11 18:03 ` Eric Biggers 2022-05-13 10:58 ` Ritesh Harjani 2022-05-13 10:58 ` Ritesh Harjani 2022-05-13 22:24 ` Eric Biggers [this message] 2022-05-13 22:24 ` Eric Biggers 2022-05-13 11:07 ` Ritesh Harjani 2022-05-13 11:07 ` [f2fs-dev] " Ritesh Harjani 2022-05-13 21:59 ` Eric Biggers 2022-05-13 21:59 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 6/7] f2fs: use the updated test_dummy_encryption helper functions Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-01 5:08 ` [PATCH v2 7/7] fscrypt: remove fscrypt_set_test_dummy_encryption() Eric Biggers 2022-05-01 5:08 ` [f2fs-dev] " Eric Biggers 2022-05-09 23:36 ` [f2fs-dev] [PATCH v2 0/7] test_dummy_encryption fixes and cleanups Eric Biggers 2022-05-09 23:36 ` Eric Biggers 2022-05-10 23:23 ` Jaegeuk Kim 2022-05-10 23:23 ` [f2fs-dev] " Jaegeuk Kim 2022-05-13 19:36 ` Theodore Ts'o 2022-05-13 19:36 ` Theodore Ts'o 2022-05-13 23:26 ` [f2fs-dev] " Eric Biggers 2022-05-13 23:26 ` 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=Yn7au5Pckn5T0iTm@sol.localdomain \ --to=ebiggers@kernel.org \ --cc=jaegeuk@kernel.org \ --cc=jlayton@kernel.org \ --cc=lczerner@redhat.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=ritesh.list@gmail.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.