Linux-FSCrypt Archive on lore.kernel.org
 help / color / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Eric Biggers <ebiggers@kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH 1/4] tune2fs: prevent changing UUID of fs with stable_inodes feature
Date: Fri, 10 Apr 2020 11:06:04 -0400
Message-ID: <20200410150604.GN45598@mit.edu> (raw)
In-Reply-To: <AC4A8A20-E23D-4695-B127-65CBCD3A3209@dilger.ca>

On Fri, Apr 10, 2020 at 05:53:54AM -0600, Andreas Dilger wrote:
> 
> Actually, I think the opposite is true here.  To avoid usability problems,
> users *have* to change the UUID of a cloned/snapshot filesystem to avoid
> problems with mount-by-UUID (e.g. either filesystem may be mounted randomly
> on each boot, depending on the device enumeration order).  However, if they
> try to change the UUID, that would immediately break all of the encrypted
> files in the filesystem, so that means with the stable_inode feature either:
> - a snapshot/clone of a filesystem may subtly break your system, or
> - you can't keep a snapshot/clone of such a filesystem on the same node

I don't think there is any reason why we would use IV_INO_LBLK_64 mode
on anything other than tablet/mobile devices using the latest UFS or
eMMC standards which support in-line crypto engines (ICE).  I'm not
aware of any cloud VM's, private or public, which supports ICE.  And
even if they did, hopefully they would use something more sane than
the UFS/eMMC spec, which only supports 64 bits of IV per I/O request,
and only support a small number of keys that can be loaded into the
hardware.  (This is what you get when you are optimizing Bill of
Materials costs down to a tenth of a cent; a million devices here,
retail store profit margins there, and before you know it you're
talking real money...)

Furthermore, on an modern x86_64, you can do AES encryption at less
than a cycle per CPU clock cycle, and in cloud VM's, battery life is
not a concern, so there really isn't any reason to use or implement
ICE, except maybe as a testing vehicle for fscrypt (e.g., someone
wanting to implement UFS 2.1 in qemu to make it easier to test the
Linux kernel's ICE support).

       	           	       	       	      	      - Ted

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 20:32 [PATCH 0/4] e2fsprogs: fix and document the " Eric Biggers
2020-04-01 20:32 ` [PATCH 1/4] tune2fs: prevent changing UUID of fs with " Eric Biggers
2020-04-02  2:19   ` Andreas Dilger
2020-04-07  5:32     ` Eric Biggers
2020-04-07 16:18       ` Andreas Dilger
2020-04-08  3:11         ` Eric Biggers
2020-04-10 11:53           ` Andreas Dilger
2020-04-10 15:06             ` Theodore Y. Ts'o [this message]
2020-04-10 16:30             ` Eric Biggers
2020-04-01 20:32 ` [PATCH 2/4] tune2fs: prevent stable_inodes feature from being cleared Eric Biggers
2020-04-01 20:32 ` [PATCH 3/4] ext4.5: document the stable_inodes feature Eric Biggers
2020-04-01 20:32 ` [PATCH 4/4] tune2fs.8: " Eric Biggers
2020-04-02  2:12   ` Andreas Dilger
2020-04-07  5:10     ` Eric Biggers
2020-04-10 15:24 ` [PATCH 0/4] e2fsprogs: fix and " Theodore Y. Ts'o
2020-05-07 18:18   ` Eric Biggers
2020-06-15 22:22     ` Eric Biggers
2020-07-27 16:45       ` Eric Biggers
2020-09-01 16:19         ` Eric Biggers
2020-09-21 22:41           ` 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=20200410150604.GN45598@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=ebiggers@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /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

Linux-FSCrypt Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/linux-fscrypt/0 linux-fscrypt/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fscrypt linux-fscrypt/ https://lkml.kernel.org/linux-fscrypt \
		linux-fscrypt@vger.kernel.org
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fscrypt


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git