From: Eric Biggers <ebiggers@google.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
Michael Halcrow <mhalcrow@google.com>,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, dedekind1@gmail.com,
adrian.hunter@intel.com, jaegeuk@kernel.org, david@sigma-star.at,
wd@denx.de, sbabic@denx.de, dengler@linutronix.de,
alexcope@google.com
Subject: Re: [PATCH 26/26] ubifs: Raise write version to 5
Date: Fri, 21 Oct 2016 11:19:31 -0700 [thread overview]
Message-ID: <20161021181931.GA90712@google.com> (raw)
In-Reply-To: <20161021174758.wz7xrulokicuhlht@thunk.org>
On Fri, Oct 21, 2016 at 01:47:59PM -0400, Theodore Ts'o wrote:
> On Fri, Oct 21, 2016 at 10:31:54AM -0700, Michael Halcrow wrote:
> > > diff --git a/fs/ubifs/ubifs-media.h b/fs/ubifs/ubifs-media.h
> > > index bdc7935a5e41..e8c23c9d4f4a 100644
> > > --- a/fs/ubifs/ubifs-media.h
> > > +++ b/fs/ubifs/ubifs-media.h
> > > @@ -46,7 +46,7 @@
> > > * UBIFS went into mainline kernel with format version 4. The older formats
> > > * were development formats.
> > > */
> > > -#define UBIFS_FORMAT_VERSION 4
> > > +#define UBIFS_FORMAT_VERSION 5
> >
> > Alex Cope is working on a fix for file name encryption in ext4 so that
> > common plaintext prefixes don't result in common ciphertext prefixes.
> > Older kernels will not be able to read the new file names.
>
> To be clear, this will be done in the context of a new encryption
> mode. In terms of how Ubifs will handle things, that's going to
> depend on whether ubifs uses a single major version number or whether
> they have a feature bitmask like other filesystems, including ext4.
>
I don't think it's reasonable to require require changes to filesystems whenever
someone introduces a new encryption mode --- contents, filenames, or both.
Filesystems need to be able to handle unsupported encryption modes in some way
that makes sense. Currently, when it sees an unsupported encryption mode
fscrypto will behave as if the encryption key is not available and will also
print a one-time warning to the kernel log. This happens when a file is
accessed, not when the filesystem is mounted. As far as I can tell, ext4, f2fs,
and ubifs would all behave this way because this code is shared. I think this
is probably the most realistic behavior.
Eric
next prev parent reply other threads:[~2016-10-21 18:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 12:48 [PATCH 00/26] UBIFS File Encryption Richard Weinberger
2016-10-21 12:48 ` [PATCH 01/26] fscrypto: Add buffer operations Richard Weinberger
2016-10-21 13:05 ` Christoph Hellwig
2016-10-21 13:17 ` Richard Weinberger
2016-10-21 13:24 ` Christoph Hellwig
2016-10-21 15:14 ` Theodore Ts'o
2016-10-24 7:05 ` Richard Weinberger
2016-10-21 12:48 ` [PATCH 02/26] fscrypto: Constify struct inode pointer Richard Weinberger
2016-10-21 14:57 ` Theodore Ts'o
2016-10-21 15:10 ` Richard Weinberger
2016-10-21 12:48 ` [PATCH 03/26] ubifs: Export ubifs_check_dir_empty() Richard Weinberger
2016-10-21 12:48 ` [PATCH 04/26] ubifs: Export xattr get and set functions Richard Weinberger
2016-10-21 12:48 ` [PATCH 05/26] ubifs: Define UBIFS crypto context xattr Richard Weinberger
2016-10-21 12:48 ` [PATCH 06/26] ubifs: Add skeleton for fscrypto Richard Weinberger
2016-10-21 12:48 ` [PATCH 07/26] ubifs: Massage ubifs_listxattr() for encryption context Richard Weinberger
2016-10-21 12:48 ` [PATCH 08/26] ubifs: Implement directory open operation Richard Weinberger
2016-10-21 12:48 ` [PATCH 09/26] ubifs: Implement file " Richard Weinberger
2016-10-21 12:48 ` [PATCH 10/26] ubifs: Enforce crypto policy in ->link and ->rename Richard Weinberger
2016-10-21 12:48 ` [PATCH 11/26] ubifs: Preload crypto context in ->lookup() Richard Weinberger
2016-10-21 12:48 ` [PATCH 12/26] ubifs: Massage assert in ubifs_xattr_set() wrt. fscrypto Richard Weinberger
2016-10-21 12:48 ` [PATCH 13/26] ubifs: Enforce crypto policy in mmap Richard Weinberger
2016-10-21 12:48 ` [PATCH 14/26] ubifs: Introduce new data node field, compr_size Richard Weinberger
2016-10-21 12:48 ` [PATCH 15/26] ubifs: Implement encrypt/decrypt for all IO Richard Weinberger
2016-10-21 17:14 ` Michael Halcrow
2016-10-21 17:21 ` Richard Weinberger
2016-10-21 17:52 ` Michael Halcrow
2016-10-21 18:21 ` Richard Weinberger
2016-10-21 18:25 ` Eric Biggers
2016-10-24 7:00 ` Richard Weinberger
2016-10-21 12:48 ` [PATCH 16/26] ubifs: Relax checks in ubifs_validate_entry() Richard Weinberger
2016-10-21 12:48 ` [PATCH 17/26] ubifs: Make r5 hash binary string aware Richard Weinberger
2016-10-21 12:48 ` [PATCH 18/26] ubifs: Constify struct inode pointer in ubifs_crypt_is_encrypted() Richard Weinberger
2016-10-21 12:48 ` [PATCH 19/26] ubifs: Implement encrypted filenames Richard Weinberger
2016-10-21 12:48 ` [PATCH 20/26] ubifs: Add support for encrypted symlinks Richard Weinberger
2016-10-21 18:42 ` Eric Biggers
2016-10-24 6:54 ` Richard Weinberger
2016-10-21 12:48 ` [PATCH 21/26] ubifs: Rename tnc_read_node_nm Richard Weinberger
2016-10-21 12:48 ` [PATCH 22/26] ubifs: Add full hash lookup support Richard Weinberger
2016-10-21 12:48 ` [PATCH 23/26] ubifs: Use a random number for cookies Richard Weinberger
2016-10-21 12:48 ` [PATCH 24/26] ubifs: Implement UBIFS_FLG_DOUBLE_HASH Richard Weinberger
2016-10-21 12:48 ` [PATCH 25/26] ubifs: Implement UBIFS_FLG_ENCRYPTION Richard Weinberger
2016-10-21 18:30 ` Eric Biggers
2016-10-24 6:59 ` Richard Weinberger
2016-10-24 13:48 ` Theodore Ts'o
2016-10-21 12:48 ` [PATCH 26/26] ubifs: Raise write version to 5 Richard Weinberger
2016-10-21 17:31 ` Michael Halcrow
2016-10-21 17:47 ` Theodore Ts'o
2016-10-21 18:19 ` Eric Biggers [this message]
2016-10-21 22:34 ` Theodore Ts'o
2016-10-24 7:03 ` Richard Weinberger
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=20161021181931.GA90712@google.com \
--to=ebiggers@google.com \
--cc=adrian.hunter@intel.com \
--cc=alexcope@google.com \
--cc=david@sigma-star.at \
--cc=dedekind1@gmail.com \
--cc=dengler@linutronix.de \
--cc=jaegeuk@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mhalcrow@google.com \
--cc=richard@nod.at \
--cc=sbabic@denx.de \
--cc=tytso@mit.edu \
--cc=wd@denx.de \
/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