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 07:27:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	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 12:49:53PM +1000, Dave Chinner wrote:
> >     The blkdicard ioctl previously only worked on block devices.  Allow
> >     this ioctl to work on ext4 files.
> >     
> >     This commit is intended to be sent upstream.
> 
> Not in that form - it's an ugly API hack.

The whole *point* was that it's an API hack.  We had a userspace
program that wanted to use the same code regardless of whether it was
accessing a block device or a file, and we didn't want to spin up a
KVM just to simulate a block device (think the whole countainers
vs. virtualization argument).

> This is really just an extension of hole punching (if the blocks in
> the file are being removed) or zeroing (if the blocks are being
> retained by the file). Either way, fallocate() is the interface
> used for per-file block level manipulations, and either of these
> operations could issue a discard (secure or not) during the
> punch/zero operation....

Except that discard is not an exact equivalent of zeroing, since even
in the case of discard zeros data, the flash device is free to
disregard the discard request if it feels like it.  But if you have a
userspace application which is trying to manage the flash to optimize
write endurance, that's different from either hole punching or
zeroing.

Secure discard maps a bit more like a zero'ing or hole punching, since
hopefully the standard for secure discard was as incompetently
authored as the discard/trim specification.  So that might be a
different approach if this is an approach that we want to get adoption
across multiple file systems.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html