Date: Thu, 11 Jan 2018 19:02:58 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225080] ZFS feature request: L2ARC and encryption compatibility: flag specifying L2ARC should hold data in encrypted form, if source is encrypted Message-ID: <bug-225080-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225080 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@FreeBSD.org Reporter: stilezy@gmail.com This is a feature request to allow full disk encryption and L2ARC to be completely compatible when using ZFS.=20 PROBLEM: Suppose geli is used to provide "data at rest" security for data in a ZFS p= ool, and the system includes L2ARC for read caching and performance. L2ARC will AFAIK always hold cached data in decrypted mform, even if the underlying di= sk is encrypted.=20 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.=20 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 fai= led disks) must forgo L2ARC, even though its performance benefits can be immens= ely useful.=20 FEATURE REQUEST: If my understanding is correct, then this could be fixed by adding a per-vo= lume 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 dat= a in L2ARC.=20 The downside is that ZFS will have to decrypt the data every read rather th= an once when it's originally read, but the decryption overhead may often be mi= nor and in return, all data at rest will then be encrypted, rather than just so= me 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 ignor= ed 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 apologi= se in advance and please close the request :) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225080-8>