linux-ext4 - Re: [PATCH] ext4: fix EXT4_IOC

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] [day] [month] [year] [list]

Date:   Thu, 8 Jul 2021 07:13:00 +0200
From:   Christoph Hellwig <hch@....de>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Christoph Hellwig <hch@....de>, leah.rumancik@...il.com,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-nvme@...ts.infradead.org
Subject: Re: [PATCH] ext4: fix EXT4_IOC_CHECKPOINT

On Wed, Jul 07, 2021 at 12:58:09PM -0400, Theodore Ts'o wrote:
> A discard is not "dangerous"; how it behaves is simply not necessarily
> guaranteed by the standards specification.  The userspace which uses
> the ioctl simply needs to know how a particular block device might
> react when it is given a discard.

A discard itself is indeed not dangerous at all.  Using it to imply
any kind of data erasure OTOH is extremely dangerous, and that is
what this interface does.

> I'll note that there is a similar issue with "WRITE SAME" or "ZEROOUT.
> A WRITE SAME might take a fraction of a second --- or it might take
> days --- depending on how the storage device is implemented.  It is
> similarly unspecified by the various standards specification.  Hence,
> userspace needs to know something about the block device before
> deciding whether or not it would be good idea to issue a "WRITE SAME"
> operation for large number of blocks.

The same is true of discard.  There are plenty of devices where
discards are horrible slow.  There also are plenty of devices where
discard is a complete no-op.  Especially on NVMe where the discard
command (DSM deallocate) is mandatory to implement.

> This is why the API is implemented in terms of what command will be
> issued to the block device, and not what the semantic meaning is for
> that particular command.  That's up to the userspace application to
> know out of band, and we should be able to give the privileged
> application the freedom to decide which command makes the most amount
> of sense.

Stop claiming you actively misleading users with broken interfaces
freedom.

> 
> 	 	      	  	    		   - Ted
---end quoted text---