All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
	Eric Biggers <ebiggers@google.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2 05/11] fscrypt: split fscrypt_dummy_context_enabled() into supp/notsupp versions
Date: Fri, 5 Jan 2018 13:18:39 -0800	[thread overview]
Message-ID: <20180105211839.GB44929@gmail.com> (raw)
In-Reply-To: <20180105204009.GA72343@jaegeuk-macbookpro.roam.corp.google.com>

On Fri, Jan 05, 2018 at 12:40:09PM -0800, Jaegeuk Kim wrote:
> On 01/05, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > fscrypt_dummy_context_enabled() accesses ->s_cop, which now is only set
> > when the filesystem is built with encryption support.  This didn't
> > actually matter because no filesystems called it.  However, it will
> > start being used soon, so fix it by moving it from fscrypt.h to
> > fscrypt_supp.h and stubbing it out in fscrypt_notsupp.h.
> 
> Ted, do we have a chance to get rid of this dummy_context? If there exists
> backward compatibility issue, please never mind tho.
> 

It's used to implement the test_dummy_encryption mount option for ext4, which is
used by the 'ext4/encrypt' config for gce-xfstests.  Its purpose is to cause all
new files (directories, regular files, and symlinks) to be automatically
encrypted with a default key, so that the encrypted I/O paths are tested more
thoroughly than by just running the 'encrypt' group tests.

There are no backward compatibility concerns with changing or removing the
test_dummy_encryption mount option; we just don't have a better solution yet.

Ideally, instead of using test_dummy_encryption we would encrypt the root
directory of the filesystem immediately after it is formatted.  However, that
doesn't work for ext4 because the lost+found directory has to be located in the
root directory, and must be unencrypted, and the lost+found directory entry must
be unencrypted.

So I think getting rid of test_dummy_encryption depends on a solution to the
lost+found problem.

An alternative would be to add support for "inherit-only" encryption policies,
then set such a policy on the root directory of the filesystem.  But, there
haven't been any requests for such a feature yet outside of this specific
testing-only use case, so I've been hesitant to add it.

Eric

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-fscrypt@vger.kernel.org,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH v2 05/11] fscrypt: split fscrypt_dummy_context_enabled() into supp/notsupp versions
Date: Fri, 5 Jan 2018 13:18:39 -0800	[thread overview]
Message-ID: <20180105211839.GB44929@gmail.com> (raw)
In-Reply-To: <20180105204009.GA72343@jaegeuk-macbookpro.roam.corp.google.com>

On Fri, Jan 05, 2018 at 12:40:09PM -0800, Jaegeuk Kim wrote:
> On 01/05, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > fscrypt_dummy_context_enabled() accesses ->s_cop, which now is only set
> > when the filesystem is built with encryption support.  This didn't
> > actually matter because no filesystems called it.  However, it will
> > start being used soon, so fix it by moving it from fscrypt.h to
> > fscrypt_supp.h and stubbing it out in fscrypt_notsupp.h.
> 
> Ted, do we have a chance to get rid of this dummy_context? If there exists
> backward compatibility issue, please never mind tho.
> 

It's used to implement the test_dummy_encryption mount option for ext4, which is
used by the 'ext4/encrypt' config for gce-xfstests.  Its purpose is to cause all
new files (directories, regular files, and symlinks) to be automatically
encrypted with a default key, so that the encrypted I/O paths are tested more
thoroughly than by just running the 'encrypt' group tests.

There are no backward compatibility concerns with changing or removing the
test_dummy_encryption mount option; we just don't have a better solution yet.

Ideally, instead of using test_dummy_encryption we would encrypt the root
directory of the filesystem immediately after it is formatted.  However, that
doesn't work for ext4 because the lost+found directory has to be located in the
root directory, and must be unencrypted, and the lost+found directory entry must
be unencrypted.

So I think getting rid of test_dummy_encryption depends on a solution to the
lost+found problem.

An alternative would be to add support for "inherit-only" encryption policies,
then set such a policy on the root directory of the filesystem.  But, there
haven't been any requests for such a feature yet outside of this specific
testing-only use case, so I've been hesitant to add it.

Eric

  reply	other threads:[~2018-01-05 21:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05 18:44 [PATCH v2 00/11] fscrypt: symlink helpers and fscrypt.h cleanup Eric Biggers
2018-01-05 18:44 ` Eric Biggers
2018-01-05 18:44 ` [PATCH v2 01/11] fscrypt: move fscrypt_has_encryption_key() to supp/notsupp headers Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 18:44 ` [PATCH v2 02/11] fscrypt: move fscrypt_control_page() " Eric Biggers
2018-01-05 18:44 ` [PATCH v2 03/11] fscrypt: move fscrypt_info_cachep declaration to fscrypt_private.h Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 18:44 ` [PATCH v2 04/11] fscrypt: move fscrypt_ctx declaration to fscrypt_supp.h Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 18:44 ` [PATCH v2 05/11] fscrypt: split fscrypt_dummy_context_enabled() into supp/notsupp versions Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 20:40   ` Jaegeuk Kim
2018-01-05 21:18     ` Eric Biggers [this message]
2018-01-05 21:18       ` Eric Biggers
2018-01-05 21:36       ` Jaegeuk Kim
2018-01-05 22:01         ` Eric Biggers
2018-01-06  0:39           ` Jaegeuk Kim
2018-01-06  2:49             ` Theodore Ts'o
2018-01-06  2:49               ` Theodore Ts'o
2018-01-05 18:44 ` [PATCH v2 06/11] fscrypt: move fscrypt_operations declaration to fscrypt_supp.h Eric Biggers
2018-01-05 18:44 ` [PATCH v2 07/11] fscrypt: move fscrypt_valid_enc_modes() to fscrypt_private.h Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 18:44 ` [PATCH v2 08/11] fscrypt: move fscrypt_is_dot_dotdot() to fs/crypto/fname.c Eric Biggers
2018-01-05 18:44   ` Eric Biggers
2018-01-05 18:45 ` [PATCH v2 09/11] fscrypt: trim down fscrypt.h includes Eric Biggers
2018-01-05 18:45   ` Eric Biggers
2018-01-05 18:45 ` [PATCH v2 10/11] fscrypt: new helper functions for ->symlink() Eric Biggers
2018-01-05 18:45   ` Eric Biggers
2018-01-05 18:45 ` [PATCH v2 11/11] fscrypt: new helper function - fscrypt_get_symlink() Eric Biggers
2018-01-12  4:33 ` [PATCH v2 00/11] fscrypt: symlink helpers and fscrypt.h cleanup Theodore Ts'o
2018-01-12  4:33   ` Theodore Ts'o
2018-01-16 23:46   ` Jaegeuk Kim

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=20180105211839.GB44929@gmail.com \
    --to=ebiggers3@gmail.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=linux-mtd@lists.infradead.org \
    --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: link
Be 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.