Re: [patch] Adding Secure Deletion to UBIFS

[Joel Reardon <joel@clambassador.com>]

This is true. The reason its done is as an optimization for the 
following reason.

When deleting a data node, the key position is marked as deleted. The key 
positions then requires a datanode read to find. By keeping it in memory (thus the TNC), 
marking a key pos as deleted doesn't require a flash read. This improves 
e.g., truncations and full file deletion speed, which would otherwise read 
each data node from flash to get the positions. If it is not stored in 
ubifs_branch (but still stored in the tree), then it would have to be 
loaded once 'on-demand' after mounting. This is also an option, of course. 
Currently, deleting a file performs a walk on all the TNC's data nodes 
that are removed, so the extra mark-delete incurs no observable cost.

Cheers,
Joel Reardon

On Wed, 29 Feb 2012, Artem Bityutskiy wrote:

> On Thu, 2012-02-09 at 16:24 +0100, Joel Reardon wrote:
>>
>> Each data nodes includes a reference to a key in the KSA. This key is read and
>> used to decrypt the data. When a new data node is written, an unused key is
>> selected from the KSA and used to encrypt the data node. The reference to the
>> key is then included with the node. The keys in the KSA are written before
>> actually being used to encrypt data. To securely delete a data node, we simply
>> mark the corresponding key position as deleted, and during the next purging
>> operation the KSA erase block that contains the key is then updated to a
>> version that does not contain the key.
>
> Why do you need to have your '__u64 crypto_lookup' both in the data node
> and the index? Isn't it enough to have them only inside the data nodes?
> ubifs_branch anyway points to the data node and you can read your
> 'crypto_lookup' from there.
>
> -- 
> Best Regards,
> Artem Bityutskiy
>