[Bug 225080] ZFS feature request: L2ARC and encryption compatibility: flag specifying L2ARC should hold data in encrypted form, if source is encrypted

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225080

            Bug ID: 225080
           Summary: ZFS feature request: L2ARC and encryption
                    compatibility: flag specifying L2ARC should hold data
                    in encrypted form, if source is encrypted
           Product: Base System
           Version: 11.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: stilezy at gmail.com

This is a feature request to allow full disk encryption and L2ARC to be
completely compatible when using ZFS. 


PROBLEM:

Suppose geli is used to provide "data at rest" security for data in a ZFS pool,
and the system includes L2ARC for read caching and performance. L2ARC will
AFAIK always hold cached data in decrypted mform, even if the underlying disk
is encrypted. 

Since L2ARC (if present) will almost always be comparatively large, probably
hundreds of GB, due to current SSD market size and pricing, and since many
crucial files are quite small, and L2ARC specifically caches frequent/recent
data, the end result is that hundreds of GB of the most common, frequently
accessed and "live" files will be cached unencrypted on SSD, even when the
encrypted volume is 'locked' or the system powered off. 

If so, then the risk of "data at rest" leakage is such that a user wanting
"data at rest" security for the system as a whole (rather than just for failed
disks) must forgo L2ARC, even though its performance benefits can be immensely
useful. 


FEATURE REQUEST:

If my understanding is correct, then this could be fixed by adding a per-volume
ZFS flag which indicates that L2ARC is to cache the encrypted (raw) data and
decrypt on the fly in RAM when necessary, rather than caching decrypted data in
L2ARC. 

The downside is that ZFS will have to decrypt the data every read rather than
once when it's originally read, but the decryption overhead may often be minor
and in return, all data at rest will then be encrypted, rather than just some
of it, making full disk encryption compatible with L2ARC from a security
perspective.


IMPLEMENTATION COMMENTS:

- Handling via a ZFS property in this way should help in two ways: (1)
transparent and backwards compatible, (2) if the disks are moved to another
platform, there's no chance of forgetting to set a sysctl or external flag and
exposing data at rest for an extended period until someone notices. Instead,
the security setting is automatically applied since it moves with the data.

- No significant compatibility issues: if a platform is running a version of
ZFS that can't understand this property, then the only effect is it's ignored
and L2ARC is never encrypted, which is the present state.

- Will geli need a hook accessible by ZFS to decrypt data if it comes from a
ZFS cache rather than directly from a disk? Alternatively, how should ZFS
decrypt the encrypted data in L2ARC?


As I'm rather new to this, if I'm mistaken and this is all wrong, I apologise
in advance and please close the request :)

-- 
You are receiving this mail because:
You are the assignee for the bug.