public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* security issue: data exposure when using block layer secure erase
@ 2022-03-16  9:37 Christoph Hellwig
  2022-03-16  9:38 ` [PATCH, alternative 1] block: remove REQ_OP_SECURE_ERASE erase Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Christoph Hellwig @ 2022-03-16  9:37 UTC (permalink / raw)
  To: axboe
  Cc: jaegeuk, chao, ulf.hansson, Adrian Hunter, Daeho Jeong,
	Eric Biggers, linux-block, linux-kernel, linux-mmc

Hi all,

while staring at the block layer code I found what I think is a major
security issue with the use of REQ_OP_SECURE_ERASE.

The issue is not about the actual protocol implementation, which only
exists for eMMC [1], but about we handle issuing the operation in the
block layer.  That is done through __blkdev_issue_discard, which
takes various parameters into account to align the issue discard
request to what the hardware prefers.  Which is perfectly fine for
discard as an advisory operation, but deadly for an operation that
wants to make data inaccessible.  The problem has existed ever since
secure erase support was added to the kernel with commit
8d57a98ccd0b ("block: add secure discard"), which added secure erase
support as a REQ_SECURE flag to the discard operation.

The ioctl added there also as the only users for a long time, until f2fs
added a second (really strange) user that uses secure erase if offered by 
the device but otherwise plain old discard: 9af846486d78
("f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl") which seems to treat the
secure discard as nice to have but actually is fine with data leaks
from the use of discard or an incorrect implementation of secure erase.

My preference would be to just remove this ill designed feature entirely.
The alternative 1 in this thead does just that.  Alternative 2 tries to
fix it instead, but I haven't bee nable to get any interested party to
actually test in more than three eeks, suggesting we're better off
removing the code.

[1] which is rather dubious as well, as sector based secure erase in
flash based media can't really work due to the lack of in-place write
support.  At best it is the equivalent for a Write Same or Write Zeroes
command without deterministic data on the next read.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-03-18 10:36 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-16  9:37 security issue: data exposure when using block layer secure erase Christoph Hellwig
2022-03-16  9:38 ` [PATCH, alternative 1] block: remove REQ_OP_SECURE_ERASE erase Christoph Hellwig
2022-03-16  9:38 ` [PATCH alternative 2] block: fix the REQ_OP_SECURE_ERASE handling to not leak erased data Christoph Hellwig
2022-03-17  9:44   ` Ulf Hansson
2022-03-18  9:11     ` Christoph Hellwig
2022-03-18 10:36       ` Ulf Hansson
2022-03-16 18:05 ` security issue: data exposure when using block layer secure erase Eric Biggers
2022-03-17  9:57   ` Joel Granados
2022-03-18  9:10   ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox