From patchwork Wed Mar 21 13:26:06 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Reardon X-Patchwork-Id: 147986 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D3CE9B6F98 for ; Thu, 22 Mar 2012 00:27:33 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SALYJ-0000GK-Bo; Wed, 21 Mar 2012 13:26:11 +0000 Received: from [78.46.68.141] (helo=eristoteles.iwoars.net) by merlin.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1SALYH-0000Fn-0g for linux-mtd@lists.infradead.org; Wed, 21 Mar 2012 13:26:10 +0000 Received: (qmail 7107 invoked by uid 5144); 21 Mar 2012 14:26:06 +0100 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Mar 2012 14:26:06 +0100 Date: Wed, 21 Mar 2012 14:26:06 +0100 (CET) From: Joel Reardon X-X-Sender: joel@eristoteles.iwoars.net To: Randy Dunlap Subject: Re: [patch] Add design document for UBIFS secure deletion In-Reply-To: <4F68E420.30801@xenotime.net> Message-ID: References: <1329152067.22240.214.camel@sauron.fi.intel.com> <1331277476.22872.2.camel@sauron.fi.intel.com> <4F68E420.30801@xenotime.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.1 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS Cc: linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Artem Bityutskiy X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Thanks for giving it a readover and finding a few errant remnants of the academic version of this design doc. With your suggestions, the update follows. cheers, Joel Reardon p.s., I'm new to this git; git format-patch gives me one patch per commit, which is a pity for a commit that e.g, fixes a typo. Format-patch doesn't obviously report how to produce unified patches. Creating a new branch, applying the patches, committing, and generating a new patch seems too much overkill but I've seen it proposed. Simpler way? --- Documentation/filesystems/ubifsec.txt | 23 ++++++++++++++--------- 1 files changed, 14 insertions(+), 9 deletions(-) diff --git a/Documentation/filesystems/ubifsec.txt b/Documentation/filesystems/ubifsec.txt index 4eb41fb..175f13d 100644 --- a/Documentation/filesystems/ubifsec.txt +++ b/Documentation/filesystems/ubifsec.txt @@ -10,9 +10,16 @@ Trivial secure deletion by overwriting the deleted data does not work for flash memory, as there is a large difference between the size of the I/O unit (page) and the erasure unit (erase block). UBIFSec encrypts each data node with a distinct key and stores the keys colocated in a key storage area (KSA). -Secure deletion is achieved by atomically updating the (small) set of erase -blocks that constitute the KSA to remove keys corresponding to deleted data, -thereby deleting the data nodes they encrypted. +Secure deletion is achieved by updating the (small) set of erase blocks that +constitute the KSA to remove keys corresponding to deleted data, thereby +deleting the data nodes they encrypted. The additional wear due to flash +erasure is small, only the erase blocks containing the keys, and the operation +of removing old keys---called purging---is done periodically so the actual +increase in wear is controled by the user. Moreover, the use of UBI's logical +erase block (LEB) interface means that the additional wear is evenly spread +over the flash memory and the new version of a LEB containing the keys can be +written using UBI's atomic update proceedure to ensure no keys are lost during +an update. Key Storage Area (KSA) ====================== @@ -83,7 +90,7 @@ node must be valid according to the index the index. The operation of purging performed on a correct key state map guarantees -DNEFS's soundness: purging securely deletes any key in the KSA marked as +soundness: purging securely deletes any key in the KSA marked as deleted---afterwards, every key either decrypts one valid data node or nothing at all and every valid data node can be decrypted. A correct key state map also guarantees the integrity of our data during purging, because no key that @@ -101,7 +108,7 @@ The key state map is built from a periodic checkpoint combined with a replay of the most recent changes while mounting. We checkpoint the current key state map to the storage medium whenever the KSA is purged. After a purge, every key is either unused or used, and so a checkpoint of this map can be -stored using one bit per key---less than 1\% of the KSA's size---which is then +stored using one bit per key---less than 1% of the KSA's size---which is then compressed. A special LEB is used to store checkpoints, where each new checkpoint is appended; when the erase block is full then the next checkpoint is written at the beginning using an atomic update. @@ -148,13 +155,11 @@ purging---taken as correct by assumption. Second, failure can occur after purging one, several, or indeed all of the KSA's LEBs. When remounting the device, the loaded checkpoint merged with the replay data reflects the state before the first purge, so some purged LEBs -contain new unused data while the key state map claims it is a deleted key. As -these are cryptographically-suitable random values, with high probability they -cannot successfully decrypt any existing valid data node. +contain new unused data while the key state map claims it is a deleted key. Third, failure can occur while writing to the checkpoint LEB. When the checkpoint is written using atomic updates, then failing during the operation -is equivalent to failing before it begins (cf. 2nd case). Incomplete +is equivalent to failing before it begins (compare the 2nd case). Incomplete checkpoints are detected and so the previous valid checkpoint is loaded instead. After replaying all the nodes, the key state map is equal to its state immediately before purging the KSA. This means that all entries marked