linux-kernel - Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

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, 28 Jun 2016 10:58:37 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Dan Williams <dan.j.williams@...el.com>,
	Yigal Korman <yigal@...xistor.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>
Subject: Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

On 06/28/16 09:33, Dan Williams wrote:
> On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman <yigal@...xistor.com> wrote:
>> Before this patch, passing a range that is beyond the physical memory
>> range will succeed, the user will see a /dev/pmem0 and will be able to
>> access it. Reads will always return 0 and writes will be silently
>> ignored.
>>
>> I've gotten more than one bug report about mkfs.{xfs,ext4} or nvml
>> failing that were eventually tracked down to be wrong values passed to
>> memmap.
>>
>> This patch prevents the above issue by instead of adding a new memory
>> range, only update a RAM memory range with the PRAM type. This way,
>> passing the wrong memmap will either not give you a pmem at all or give
>> you a smaller one that actually has RAM behind it.
>>
>> And if someone still needs to fake a pmem that doesn't have RAM behind
>> it, they can simply do memmap=XX@YY,XX!YY.
>>
>> Signed-off-by: Yigal Korman <yigal@...xistor.com>
>> Acked-by: Dan Williams <dan.j.williams@...el.com>
>> Acked-by: Johannes Thumshirn <jthumshirn@...e.de>
>> Tested-by: Boaz Harrosh <boaz@...xistor.com>
>> ---
> 
> I have some other libnvdimm fixes heading upstream shortly if x86
> folks just want to ack this one...
> 

I'm concerned about this.  This would mean that memory not marked as RAM
because it is persistent and you don't want the OS to accidentally
clobber persistent RAM can't be added.  So it seems like The Wrong
Thing.  If all you want is simulated pram then it shouldn't care about
addresses in the first place and instead we should just specify it by
quantity.

	-hpa