linux-kernel - Re: security issue: data exposure when using block layer secure erase

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]

Message-ID: <20220317095756.vqfdxb5gd5nvuank@joelS1.panther.com>
Date:   Thu, 17 Mar 2022 10:57:56 +0100
From:   Joel Granados <j.granados@...sung.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Christoph Hellwig <hch@....de>, axboe@...nel.dk,
        jaegeuk@...nel.org, chao@...nel.org, ulf.hansson@...aro.org,
        Adrian Hunter <adrian.hunter@...el.com>,
        Daeho Jeong <daehojeong@...gle.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org
Subject: Re: security issue: data exposure when using block layer secure
 erase

On Wed, Mar 16, 2022 at 06:05:29PM +0000, Eric Biggers wrote:
> On Wed, Mar 16, 2022 at 10:37:40AM +0100, Christoph Hellwig wrote:
> > 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.
> 
> __blkdev_issue_discard() can break up the region into multiple bios, but I don't
> see where it actually skips parts of the region.  Can you explain more
> specifically where the problem is?
> 
> - Eric

I'm also not seeing it.

As I read the __blkdev_issue_discard() function it uses
discard_granularity to define the required sectors (req_sects) for each
bio. req_sects can change on every iteration of the while loop, but
all consecutive bios then start where the previous one ended.

Am I missing something?

Joel

Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)