From: "Theodore Ts'o" <tytso@mit.edu>
To: Richard Weinberger <richard@nod.at>
Cc: Eric Biggers <ebiggers@google.com>,
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
Subject: Re: [PATCH 25/26] ubifs: Implement UBIFS_FLG_ENCRYPTION
Date: Mon, 24 Oct 2016 09:48:16 -0400 [thread overview]
Message-ID: <20161024134816.sihgrniryifo6n63@thunk.org> (raw)
In-Reply-To: <58235996-2da6-259c-a02c-9e7fcb499d62@nod.at>
On Mon, Oct 24, 2016 at 08:59:26AM +0200, Richard Weinberger wrote:
>
> So, on ext4 (f2fs too?) root has to enable to feature first before users
> can use it?
> IOW for ext4 the encryption flag means "file encryption is allowed", for UBIFS it
> means "at least one file got encrypted on this fs".
Historically there have been one or two feature flags which ext4 has
enabled automatically, behind the system administrator's back. We've
since decided that's a bad thing to do, and so it's a file system
level policy not to do this.
An example of why this can cause problems is if a system administrator
boots a rescue CD that happens to use a newer kernel, and that newer
kernel (plus potentially an updated userspace on said rescue CD)
silently the feature flag to enable some feature (say, the first time
we have files larger than 2GB, for example), and then when the system
administrator books back into their RHEL or SLES kernel, they can no
longer mount the file system.
So ext4 has a policy now that we won't do that, since it's unfriendly
to system administrators. That's a general rule, and not one which is
specific to encryption. That way you can create a file system, and
for the most part, modulo some really old, ancient flags which
hopefully all Linux systems understand (I don't *think* there are any
RHEL 2.x systems out there still :-), if a feature flag is not
enabled, the kernel will return an error if you try to use some
feature which is not enabled, instead of silently enabling it behind
the user and/or sysadmin's back.
I believe xfs may have a similar policy, and for similar reasons.
(Actually, I'm not sure if xfs supports enabling features after the
file system has been created at all; certainly Red Hat has a
distro-level policy of not supporting features added post-mkfs,
although I don't know how much that is enforced at the open source
coding level. At one point there were some grumbles that Red Hat
might want to disable some of tune2fs's features of enabling features
post-mkfs time, but I think they've settled for just laughing at users
who show up with bug reports after they converted a file system from
ext3 to ext4. :-)
> I think I'll do what ext4 does to have common policies.
If you want to, feel free; but if there is good reason for Ubifs to
want to be more flexible, I think there is room for differences at
this level.
The specific reason why we do this probably doesn't matter so much on
embedded systems --- although I will note that many/most handset
manufacturers have a policy of not supporting any new features that
require new *kernel* fatures after the device has been released,
because they don't want to deal with potential upgrade problems and
device instabilities issues; users tend to get unhappy when their
phones get bricked after an upgrade.
Cheers,
- Ted
next prev parent reply other threads:[~2016-10-24 13:48 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 [this message]
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
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=20161024134816.sihgrniryifo6n63@thunk.org \
--to=tytso@mit.edu \
--cc=adrian.hunter@intel.com \
--cc=david@sigma-star.at \
--cc=dedekind1@gmail.com \
--cc=dengler@linutronix.de \
--cc=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=sbabic@denx.de \
--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
all inboxes | Powered by JetHome®