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 :)
Why not just use a geli device to back your L2ARC? I don't see why this needs to be more complicated than that.
$ zpool add <pool> cache <device>.eli No? If so, I suspect this can be CLOSED "Not a bug" or "Works as intended."
This has been discussed and documented externally, e.g., http://blog.branix.net/freebsd-hints/en
I f you are using GELI or similar, please do use it for the cache as well, just as Conrad suggested. OpenZFS is growing native encryption support and I am confident that the cache encryption is properly handled there. But you don't have to take my word for it. In any case, the proposed design is a big layering violation and is much harder to implement that it may sound. So, we are not going to do it. If you had a patch, then it could be a slightly different story. But only slightly.