lkml.org 
[lkml]   [2018]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2/2] jffs2: Provide jffs2_sync files to track gc POLL progress
Date
On 07/23/2018 01:17 AM, Richard Weinberger wrote:
> Beside of that, IMHO this debugfs file is a gross hack.
> Did you look into the possibility to add the GC phase into the unlink code?
I'm not terribly keen on it either, but it's the least bad option I
could think of.  The main issue is that this kind of forced GC can be
very slow (typically 2min on my test platform), and is not necessary for
the vast majority of unlink cases - we only need to securely delete
keys, other files can be cleaned up eventually. Unlink calls have no way
of identifying such sensitive files, however, nor is there a way of
demarcating a series of back-to-back secure deletions that can be
collected en masse.  Parallel to the problem of triggering the forced
GC, is the issue of knowing when it has completed: blocking on file read
seemed to be the most digestible to userspace way of doing that.

Alternatives I've considered include overwrite-before-unlink (the block
history gets complicated, plus the problem of actually doing such an
overwrite), automatic GC on unlink (see above), an alternative system
call for secure unlink (that messes up the entire FS call chain), and
encrypting the sensitive files (key to access keys must also be
persistent, which gets us back to the same problem).  In my original
version I'd used a /proc file, but debugfs has a more forgiving social
contract.

Regards,

Theuns
KRN
\
 
 \ /
  Last update: 2018-07-23 00:22    [W:0.060 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site