linux-kernel - Re: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports an internal cache

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]

Date:   Tue, 21 Mar 2023 05:37:27 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-mmc@...r.kernel.org,
        Wenchao Chen <wenchao.chen666@...il.com>,
        Avri Altman <avri.altman@....com>,
        Christian Lohle <cloehle@...erstone.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bean Huo <beanhuo@...ron.com>
Subject: Re: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports
 an internal cache

On Mon, Mar 20, 2023 at 04:24:36PM +0100, Ulf Hansson wrote:
> > Neither to ATA or SCSI, but applications and file systems always very
> > much expected it, so withou it storage devices would be considered
> > fault.  Only NVMe actually finally made it part of the standard.
> 
> Even if the standard doesn't say, it's perfectly possible that the
> storage device implements it.

That's exactly what I'm saying above.

> > But these are completely separate issue.  Torn writes are completely
> > unrelated to cache flushes.  You can indeed work around torn writes
> > by checksums, but not the lack of cache flushes or vice versa.
> 
> It's not a separate issue for eMMC. Please read the complete commit
> message for further clarifications in this regard.

The commit message claims that checksums replace cache flushes.  Which
is dangerously wrong.  So please don't refer me to it again - this
dangerously incorrect commit message is wht alerted me to reply to the
patch.

> > > However, the issue has been raised that reliable write is not
> > > needed to provide sufficient assurance of data integrity, and that
> > > in fact, cache flush can be used instead and perform better.
> >
> > It does not.
> 
> Can you please elaborate on this?

Flushing caches does not replace the invariant of not tearing subsector
writes.  And if you need to use reliable writes for (some) devices to
not tear sectors, no amount of cache flushing is going to paper over
the problem.