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

["Lukáš Czerner" <lczerner@redhat.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1826 bytes --]

On Tue, 17 Jun 2014, JP Abgrall wrote:

> Date: Tue, 17 Jun 2014 10:53:21 -0700
> From: JP Abgrall <jpa@google.com>
> To: Theodore Ts'o <tytso@mit.edu>
> Cc: Lukáš Czerner <lczerner@redhat.com>, Dave Chinner <david@fromorbit.com>,
>     Eric Sandeen <sandeen@redhat.com>, linux-ext4@vger.kernel.org,
>     Geremy Condra <gcondra@google.com>,
>     "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
> Subject: Re: [PATCH] ext4: Add support for SFITRIM,
>     an ioctl for secure FITRIM.
> 
> On Tue, Jun 17, 2014 at 6:54 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> >
> > There's an assumption here that the eMMC SECDISCARD functionality is
> > more competently spec'ed out compared to the ATA/SCSI interface.  I'm
> > not sure whether or not that's true, but perhaps JP and Geremy can
> > confirm that.
> We only care about the eMMC spec. In the eMMC spec there is no room
> for ignoring the commands. If the card declares it can do a secure
> erase/trim it must do it as per the spec.

Except when it does not. Looking at the mmc driver I can see that we
have already some devices where secure trim is broken.

/*
 * On these Samsung MoviNAND parts, performing secure erase or
 * secure trim can result in unrecoverable corruption due to a
 * firmware bug.
 */

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.

Btw, AFACIT with this backlisted hardware the user will not even
notice that secure discard did not went through and the driver will
simply use normal discard, which is a bug if you ask me.

Let's call is deep discard, or whatever but avoid the security word
at least when file system comes into play.

-Lukas

>   JEDEC Standard No. 84-A441
>   7.6.9 Secure Erase
>   7.6.10 Secure Trim