Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 17 Mar 2022 10:57:56 +0100
From:   Joel Granados <j.granados@samsung.com>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Christoph Hellwig <hch@lst.de>, axboe@kernel.dk,
        jaegeuk@kernel.org, chao@kernel.org, ulf.hansson@linaro.org,
        Adrian Hunter <adrian.hunter@intel.com>,
        Daeho Jeong <daehojeong@google.com>,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mmc@vger.kernel.org
Subject: Re: security issue: data exposure when using block layer secure
 erase
Message-ID: <20220317095756.vqfdxb5gd5nvuank@joelS1.panther.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512";
        protocol="application/pgp-signature"; boundary="ytpb7p6j66wf776p"
Content-Disposition: inline
In-Reply-To: <YjIm6f6pSX1CKeqb@gmail.com>
CMS-TYPE: 201P
References: <20220316093740.GA7714@lst.de>
        <CGME20220316180540eucas1p2179a720cb484c46f396978eaec8c6aa6@eucas1p2.samsung.com>
        <YjIm6f6pSX1CKeqb@gmail.com>
Precedence: bulk

--ytpb7p6j66wf776p
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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,
> >=20
> > 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.
> >=20
> > 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.
>=20
> __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?
>=20
> - 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

--ytpb7p6j66wf776p
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmIzBh0ACgkQupfNUreW
QU9p7Qv/UfKXFyL6aVj6F7OKUsiqBC100Z9LAW/CcxJj1VRxfvO2OF3NKt+hunId
Wct6qqrxzvTv0WG3qb0mKLkGj+hbMiJg3SuIVAYewlQHFxsmFExuACV7KFLt/wUJ
N+/tQtzf3QRwzvB5L2nQ+nn0MrS/32iStn4mpyZuR8E3FSD9ArlPB9mZdwS+Lq85
dhYMLkRcd491uYZtBZYEJ+fFtR7xbw5vy+LcmnvJoLeBjNGEiLUQCO7rXGFOBNPP
M2Kc73Jl/7wZLZOdmxEti6ecNtLkfC3DAQSM74utDZjAsunqK7PYvwPOsc288hOC
fwfZfY1+yW1cGHsu+JZQJc9bMsNfk41qmyM74cPqhFM3Iar77c6g9UC5lbY9aj3X
LiAKoVORGCH85CQb9tqi/20GLdxo2iOfM4TbcxxT8eJMPhT0PHV0JJy2C5eXwyGq
FpMgixPMKgkYxcarDwhuVLqXPtMvIBVDoVXtWZVZZeQw01DEGipmOo7VufKnnjS+
F2Lvrrqw
=4Qk6
-----END PGP SIGNATURE-----

--ytpb7p6j66wf776p--