linux-kernel - Re: First kernel patch (optimization)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2015 10:59:38 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Theodore Ts'o <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Eric Curtin <ericcurtin17@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

Am 20.09.2015 um 12:41 schrieb Alexander Holler:
> Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:

>> As far as what you want to do next, you have a personal "proof of
>> concept" patch that seems to work well enough for you.  Great!  I'm
>> sure you can keep using it for your own purposes.  If you can convince
>> someone with the skills to get the patch to an upstreamable state, it
>> is my judgement that this is doable, so this puts your feature in a
>> much better state than the FALLOC_FL_NO_HIDE_STALE flag.  However,
>> there is still a non-trivial amount of work left to do to turn your
>> "proof of concept" patch into something that is upstremable, including
>> changing the interface to using the FS_SECRM_FL flag.  And your
>> whining that other people should change *their* priorities to match
>> *yours* is not likely to help.
>
> Besides that I have absolutely no knowledge about
> FALLOC_FL_NO_HIDE_STALE or the FS_SECRM_FL flag, I've never whined. I've
> complained about the tone very often used on this list. And it doesn't

Just to explain why I'm still quiet happy with my very simple approach 
to use a simple modified discard mechanism to wipe files:

My main use case (an that of several other people I know) is to have a 
simple way to wipe photos on sd-cards or to wipe other files I've copied 
once onto (vfat-formatted) usb-sticks while never having modified these 
files afterwards.

And that works like a charm and doesn't need complicated patches which 
might be very different for every filesystem.

And the check (and returning an error) if a file is already in use when 
trying to wipe it, makes it unnecessary to introduce something more 
complicated to schedule wiping. I also don't care if something is left 
in swap or similiar. So instead of trying to perfectly solve a big 
problem (which already was unsuccessful tried in case of the Linux 
kernel), I've just reduced the problem to fit the main use cases most 
people have and solved that with a very simple, but working approach.

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/