linux-kernel - Re: [PATCH 00/13] deprecate pcommit

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:	Sun, 5 Jun 2016 18:48:15 +0000
From:	"Rudoff, Andy" <andy.rudoff@...el.com>
To:	Andy Lutomirski <luto@...capital.net>,
	"Williams, Dan J" <dan.j.williams@...el.com>
CC:	X86 ML <x86@...nel.org>,
	Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
	linux-nvdimm <linux-nvdimm@...ts.01.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Dave Chinner <david@...morbit.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Christoph Hellwig <hch@....de>,
	Peter Zijlstra <peterz@...radead.org>,
	"Ingo Molnar" <mingo@...hat.com>,
	"Hunter, Adrian" <adrian.hunter@...el.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH 00/13] deprecate pcommit

>> Platforms supporting NVDIMMs are now required to provide persistence
>> guarantees once pmem stores are accepted by the memory subsystem.
>
>Can you point us to a precise definition of what exactly constitutes
>stores being "accepted by the memory subsystem"?  Back when pcommit
>was a thing (hah!), it was precisely documented in the SDM.

The Instruction Set Extensions document that describes PCOMMIT
says it applies to stores that were accepted by the memory subsystem
but were still potentially queued there.  So Dan’s description was
building on that same language.  A concrete example might help:

MOV to location X
CLWB X
SFENCE

is the sequence for flushing a store to pmem.  Before PCOMMIT
was deprecated, software needed to understand if the platform
had ADR and add:

PCOMMIT       ; the old way
SFENCE            ; the old way

to the above sequence if ADR wasn’t present on the platform.  Now
that ADR is required for all persistent memory, as it always has
been for NVDIMM-N devices available today, the simpler programming
model already in use for NVDIMM-N is used for all pmem.

>> is usually achieved by a platform-level feature known as ADR
>> (Asynchronous DRAM Refresh) that flushes any memory subsystem write
>> pending queues on power loss/shutdown.
>
>Blech.  Does this mean that we need some NMI handler or similar that
>does wbinvd?  Will CPU caches automatically write themselves back on
>power loss?  Will we lose data if something goes wrong with an SMI
>handler?

No, ADR is a platform-level feature that flushes any buffers in the memory
subsystem on power loss.  No software is involved and the CPU caches are
not touched by ADR.  So any stores flushed by CLFLUSH, CLFLUSHOPT, CLWB,
WBINVD, or non-temporal stores that go around the CPU caches can now be
considered persistent once those operations are complete.

>> The 'pcommit' instruction (which has not shipped on any product) is no
>> longer needed and is deprecated.
>
>Does this mean it will never ship?

Yes.  The new instructions like CLWB and CLFLUSHOPT will be rolled
into the SDM but PCOMMIT will be removed from the Extensions doc
and not rolled into the SDM.

-andy