linux-kernel - Re: NVM Mapping API

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:	Thu, 17 May 2012 15:06:18 -0400
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	Vyacheslav Dubeyko <slava@...eyko.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: NVM Mapping API

On Wed, May 16, 2012 at 05:58:49PM -0400, Benjamin LaHaise wrote:
> The big question I have is what the actual interface for these types of 
> memory will be.  If they're like actual RAM and can be mmap()ed into user 
> space, it will be preferable to avoid as much of the overhead of the existing 
> block infrastructure that most current day filesystems are built on top of.  

Yes.  I'm hoping that filesystem developers will indicate enthusiasm
for moving to new APIs.  If not the ones I've proposed, then at least
ones which can be implemented more efficiently with a device that looks
like DRAM.

> If the devices have only modest endurance limits, we may need to stick the 
> kernel in the middle to prevent malicious code from wearing out a user's 
> memory cells.

Yes, or if the device has long write latencies or poor write bandwidth,
we'll also want to buffer writes in DRAM.  My theory is that this is
doable transparently to the user; we can map it read-only, and handle
the fault by copying from NVM to DRAM, then changing the mapping and
restarting the instruction.  The page would be written back to NVM on
a sync call, or when memory pressure or elapsed time dictates.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/