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
|