linux-ext4 - Re: [PATCH] ext4: Add support for SFITRIM, an ioctl for secure FITRIM.

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:	Tue, 17 Jun 2014 15:00:40 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
cc:	Dave Chinner <david@...morbit.com>, JP Abgrall <jpa@...gle.com>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
	Geremy Condra <gcondra@...gle.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] ext4: Add support for SFITRIM, an ioctl for secure
 FITRIM.

On Tue, 17 Jun 2014, Theodore Ts'o wrote:

> Date: Tue, 17 Jun 2014 08:46:29 -0400
> From: Theodore Ts'o <tytso@....edu>
> To: Lukáš Czerner <lczerner@...hat.com>
> Cc: Dave Chinner <david@...morbit.com>, JP Abgrall <jpa@...gle.com>,
>     Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
>     Geremy Condra <gcondra@...gle.com>,
>     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
> Subject: Re: [PATCH] ext4: Add support for SFITRIM,
>     an ioctl for secure FITRIM.
> 
> On Tue, Jun 17, 2014 at 01:55:26PM +0200, Lukáš Czerner wrote:
> > 
> > I definitely agree with Dave here it is an ugly API hack. Fallocate
> > seems much more suitable for this.
> > 
> > New flag FALLOC_FL_ISSUE_DISCARD which would work with
> > FALLOC_FL_PUNCH_HOLE, FALLOC_FL_ZERO_RANGE and possibly
> > FALLOC_FL_COLLAPSE_RANGE might actually be useful.
> 
> I agree it would be useful to have an FL_ISSUE_DISCARD (and while
> we're at it, FL_ISSUE_SECDISCARD) as an fallocate flag.  That doesn't
> obviate the usefulness of a BLKDISCARD ioctl for ext4 files, though.
> 
> Something else that might be useful, and perhaps more appropriate for
> the Android use case, is to add a SECDISCARD flag to the unlinkat(2)
> system call.  That way, people who want to do a "discard and then
> unlink" don't have to be forced to do an open(2), fallocate(2),
> close(2), and only *then* the unlink(2) system call.

What is the difference between -o discard mount option ? I guess
that this way you can do it selectively on certain files, but I
wonder how useful it is going to be anyway ?

Nevertheless, I think that there is a conclusion that there is no
"security" to be had with file system and SECDISCARD. And no secure
erase with this type of interface would be "secure" enough.

If they are ok with only best effort, then we can have FISTRIM ioctl
which would use the same internal file system functionality as
FITRIM but we would add a flag to be able to call sb_issue_discard()
with BLKDEV_DISCARD_SECURE flag, disable the optimization to skip
already discarded groups and call sync on the file system before we
start doing any actuall work. I wish I added flags to the FITRIM
ioctl when I created it...

If we do this though we should not add word "security" anywhere for
the use to see :)

-Lukas

> 
> Cheers,
> 
> 						- Ted
>