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:	Thu, 19 Jun 2014 10:15:49 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Dave Chinner <david@...morbit.com>
cc:	"Theodore Ts'o" <tytso@....edu>, 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 Thu, 19 Jun 2014, Dave Chinner wrote:

> Date: Thu, 19 Jun 2014 10:36:57 +1000
> From: Dave Chinner <david@...morbit.com>
> To: Theodore Ts'o <tytso@....edu>
> Cc: Lukáš Czerner <lczerner@...hat.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 Wed, Jun 18, 2014 at 06:06:01PM -0400, Theodore Ts'o wrote:
> > On Wed, Jun 18, 2014 at 11:33:47AM +0200, Lukáš Czerner wrote:
> > > And I have no illusion that those are the only ones that does not
> > > work. This hardware can not be trusted and this must not be
> > > advertised as a security feature.
> > 
> > There's always crappy hardware out there.  If that's true, should then
> > not call ATA Secure Erase by that term because somewhere out there,
> > there will be an incompetently implemented SSD that doesn't do the
> > right thing with ATA Secure Erase?  I just don't think that's
> > particularly useful.  If the command is called "secure erase" or
> > "secure discard" in the specification, then that's what we should use,
> > just to avoid confusion if nothing else.
> 
> That's just a steaming pile of rhetoric. If that was true, then we
> wouldn't be calling our operations BLKDISCARD or "discard", would
> we?  It would be called "TRIM" or "WRITE_SAME" because that's what
> the device layer standards call the operations.
> 
> Sure, we have a "FITRIM" ioctl, but we acknowledged early on that it
> was badly named because different protocols use different names.
> That's why we started to use "discard" instead - it's a protocol and
> device neutral term that describes the intent of the operation - to
> -discard blocks-.
> 
> IOWs, I think that Lukas is right on the money here - we should not
> imply something is secure when it is not, nor should we name high
> level interfaces based on the standardise name on the low level
> primitive some class of device or protocol uses. 
> 
> Rather, we should describe it for what it is: it is a command
> to *scrub the data* from a range of blocks. i.e. it's not a
> discard operation at all - it's a "scrub" operation that we are
> asking the device to perform.
> 
> And further, scrubbing has a specific meaning in the security
> environment - it doesn't imply security - it just means there is a
> mechanism for physically removing data from it's known locations.
> Security comes from what you do with the scrubbing mechanism at
> higher layers.
> 
> Scrubbing is something people already understand and it's clear
> that it's a data manipulation operation and not some magic "secure"
> operation. And by calling it "scrub" we get away from the idea that
> it only works on specific hardware - hardware acceleration is good,
> but there's no reason why we should design the functionality to only
> be useful on systems with hardware scrubbing capability...

+1 for the "scrub" operation, it makes perfect sense to me.

-Lukas

> 
> Cheers,
> 
> Dave.
>