From owner-freebsd-bugs@freebsd.org Thu Jan 11 19:02:58 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0C1DE75F53 for ; Thu, 11 Jan 2018 19:02:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6201807E9 for ; Thu, 11 Jan 2018 19:02:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id AAADC32C9 for ; Thu, 11 Jan 2018 19:02:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w0BJ2wPY058966 for ; Thu, 11 Jan 2018 19:02:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w0BJ2wTY058965 for freebsd-bugs@FreeBSD.org; Thu, 11 Jan 2018 19:02:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Thu, 11 Jan 2018 19:02:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: stilezy@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 19:02:58 -0000 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.=