linux-ext4 - Re: [PATCH 1/4] tune2fs: prevent changing UUID of fs with stable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Apr 2020 11:06:04 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        linux-fscrypt@...r.kernel.org
Subject: Re: [PATCH 1/4] tune2fs: prevent changing UUID of fs with
 stable_inodes feature

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