So there's a matrix of possible configurations.  If you're doing a
reflink between subvolumes and you're doing a subvolume granular
encryption and you don't have keys to the source subvolume, the reflink
shouldn't be allowed.

 Right, this is working.

If you do have keys, any new writes are happening
into a different inode, and will be encrypted with a different key.

 As of now it returns -EXDEV. But I should change this.

If you're doing a file level encryption and you do have access to the
source file, the destination file is a new inode.  Thanks to COW any
changes are going to go into new extents and will end up with different

Either way, we degrade down into extent based encryption.  I'd take that
hit to maintain sane semantics in the face of snapshots and reflinks.
The btrfs extent structures on disk already have an encryption type field.

 Agreed. About keys.. a file might need N number of keys (N = number of
 extents) to open.

Thanks, Anand

So in any case, assuming you're using block encryption (which is what
fscrypt uses) there really isn't a problem with nonce reuse, although
in some cases if you really do want to reflink a file and have it be
protected by different user keys, this would have to force copy of the
duplicated blocks at that point.  But arguably, that is a feature, not
a bug.  If the two users are mutually suspicious, you don't _want_ to
leak information about who much of a particular file had been changed
by a particular user.  So you would want to break the reflink and have
separate copies for both users anyway.

One final thought --- something which is really going to be a factor
in many use cases is going to be hardware accelerated encryption.  For
example, Qualcomm is already shipping an SOC where the encryption can
be done in the data path between the CPU and the eMMC storage device.
If you want to support certain applications that try to read megabytes
and megabytes of data before painting a single pixel, in-line hardware
crypto at line speeds is going to be critical if you don't want to
sacrifice performance, and keep users from being cranky because it
took extra seconds before they could start reading their news feed (or
saving bird eggs from voracious porcine predators, or whatever).

This may very well be an issue in the future not just for mobile
devices, but I could imagine this potentially being an issue for other
form factors as well.  Yes, Skylake can encrypt multiple bytes per
clock cycle using the miracles of hardware acceleration and
pipelining.  But in-line encryption will still have the advantage of
avoiding the memory bandwidth costs.  So while it is fun to talk about
exotic encryption modes, it would be wise to have file system
encryption architectures to have modes which are compatible with
hardware in-line encryption schemes.

Strongly agree here.  This is the whole reason btrfs used crc32c, but
times 100 (or maybe 1000).  I love that  Kent and others are
experimenting in bcachefs and elsewhere.  Btrfs can always bring in new
schemes that work well once the framework is in place, but its not an
area where I have enough expertise to get exotic on the first try.

To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
More majordomo info at
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
More majordomo info at

Reply via email to