Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934598AbcJURtk (ORCPT <rfc822;w@1wt.eu>);
        Fri, 21 Oct 2016 13:49:40 -0400
Received: from imap.thunk.org ([74.207.234.97]:58248 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S933608AbcJURtf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 21 Oct 2016 13:49:35 -0400
Date: Fri, 21 Oct 2016 13:47:59 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Michael Halcrow <mhalcrow@google.com>
Cc: 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
Message-ID: <20161021174758.wz7xrulokicuhlht@thunk.org>
Mail-Followup-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
References: <1477054121-10198-1-git-send-email-richard@nod.at>
 <1477054121-10198-27-git-send-email-richard@nod.at>
 <20161021173154.GB17121@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161021173154.GB17121@google.com>
User-Agent: NeoMutt/20160916 (1.7.0)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2127
Lines: 45

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.

This is better because if the user doesn't use a particular feature,
especially a feature like encryption which is optional, we don't want
the file system to reject the mount unnecessarily.  In the case of
encryption, where there may be new encryption algorithms used, or
maybe even hardware-specific encryption modes if you are using in-line
encryption where the encryption is done in hardware, the question is
whether you want to refuse the mount if you know it won't work, or
just throw an error when there is an attempt to access a directory or
file which is encrypted using an encryption algorithm which a
particular kernel version doesn't support.

We did leave some room in the ext4 superblock for an encryption format
version number, as ewll as an array of which encryption algorithsm are
in use in the superblock, but we haven't really decided which strategy
we want to use.

My current thinking is that there ought to be a warning at mount time
if there are some directories which the kernel being used won't be
able to access, but we should just fail the mount entirely, since
there might be a lot of unencrypted files that the user might want to access.

Cheers,

							- Ted