All of lore.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; 10+ 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] 10+ messages in thread
* Re: [PATCH alternative 2] block: fix the REQ_OP_SECURE_ERASE handling to not leak erased data
@ 2022-03-18 22:31 kernel test robot
  0 siblings, 0 replies; 10+ messages in thread
From: kernel test robot @ 2022-03-18 22:31 UTC (permalink / raw)
  To: kbuild

[-- Attachment #1: Type: text/plain, Size: 4218 bytes --]

CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <20220316093855.GC7714@lst.de>
References: <20220316093855.GC7714@lst.de>
TO: Christoph Hellwig <hch@lst.de>
TO: axboe(a)kernel.dk
CC: jaegeuk(a)kernel.org
CC: chao(a)kernel.org
CC: ulf.hansson(a)linaro.org
CC: Adrian Hunter <adrian.hunter@intel.com>
CC: Daeho Jeong <daehojeong@google.com>
CC: Eric Biggers <ebiggers@google.com>
CC: linux-block(a)vger.kernel.org
CC: linux-kernel(a)vger.kernel.org
CC: linux-mmc(a)vger.kernel.org

Hi Christoph,

I love your patch! Perhaps something to improve:

[auto build test WARNING on jaegeuk-f2fs/dev-test]
[also build test WARNING on linux/master linus/master v5.17-rc8]
[cannot apply to axboe-block/for-next next-20220318]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Christoph-Hellwig/block-fix-the-REQ_OP_SECURE_ERASE-handling-to-not-leak-erased-data/20220316-174028
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev-test
:::::: branch date: 3 days ago
:::::: commit date: 3 days ago
config: x86_64-randconfig-m001-20220314 (https://download.01.org/0day-ci/archive/20220319/202203190620.wyBlW8VG-lkp(a)intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>

New smatch warnings:
block/blk-lib.c:464 blkdev_issue_secure_erase() warn: should 'len << 9' be a 64 bit type?

Old smatch warnings:
block/blk-lib.c:465 blkdev_issue_secure_erase() warn: should 'len << 9' be a 64 bit type?

vim +464 block/blk-lib.c

04d790607abc51e Christoph Hellwig 2022-03-16  436  
04d790607abc51e Christoph Hellwig 2022-03-16  437  int blkdev_issue_secure_erase(struct block_device *bdev, sector_t sector,
04d790607abc51e Christoph Hellwig 2022-03-16  438  		sector_t nr_sects, gfp_t gfp)
04d790607abc51e Christoph Hellwig 2022-03-16  439  {
04d790607abc51e Christoph Hellwig 2022-03-16  440  	sector_t bs_mask = (bdev_logical_block_size(bdev) >> 9) - 1;
04d790607abc51e Christoph Hellwig 2022-03-16  441  	unsigned int max_sectors =
04d790607abc51e Christoph Hellwig 2022-03-16  442  		bdev_get_queue(bdev)->limits.max_discard_sectors;
04d790607abc51e Christoph Hellwig 2022-03-16  443  	struct bio *bio = NULL;
04d790607abc51e Christoph Hellwig 2022-03-16  444  	struct blk_plug plug;
04d790607abc51e Christoph Hellwig 2022-03-16  445  	int ret = 0;
04d790607abc51e Christoph Hellwig 2022-03-16  446  
04d790607abc51e Christoph Hellwig 2022-03-16  447  	if (max_sectors == 0)
04d790607abc51e Christoph Hellwig 2022-03-16  448  		return -EOPNOTSUPP;
04d790607abc51e Christoph Hellwig 2022-03-16  449  	if ((sector | nr_sects) & bs_mask)
04d790607abc51e Christoph Hellwig 2022-03-16  450  		return -EINVAL;
04d790607abc51e Christoph Hellwig 2022-03-16  451  	if (bdev_read_only(bdev))
04d790607abc51e Christoph Hellwig 2022-03-16  452  		return -EPERM;
04d790607abc51e Christoph Hellwig 2022-03-16  453  
04d790607abc51e Christoph Hellwig 2022-03-16  454  	blk_start_plug(&plug);
04d790607abc51e Christoph Hellwig 2022-03-16  455  	for (;;) {
04d790607abc51e Christoph Hellwig 2022-03-16  456  		unsigned int len = min_t(sector_t, nr_sects, max_sectors);
04d790607abc51e Christoph Hellwig 2022-03-16  457  
04d790607abc51e Christoph Hellwig 2022-03-16  458  		bio = blk_next_bio(bio, 0, gfp);
04d790607abc51e Christoph Hellwig 2022-03-16  459  		bio_set_dev(bio, bdev);
04d790607abc51e Christoph Hellwig 2022-03-16  460  		bio->bi_opf = REQ_OP_SECURE_ERASE;
04d790607abc51e Christoph Hellwig 2022-03-16  461  		bio->bi_iter.bi_sector = sector;
04d790607abc51e Christoph Hellwig 2022-03-16  462  		bio->bi_iter.bi_size = len;
04d790607abc51e Christoph Hellwig 2022-03-16  463  
04d790607abc51e Christoph Hellwig 2022-03-16 @464  		sector += len << SECTOR_SHIFT;

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

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

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

Thread overview: 10+ 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
  -- strict thread matches above, loose matches on Subject: below --
2022-03-18 22:31 [PATCH alternative 2] block: fix the REQ_OP_SECURE_ERASE handling to not leak erased data kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.