linux-kernel - Re: What can change in ways Linux handles memory when all memory >4G is disabled? (x86)

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, 08 Jun 2014 10:53:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Nikolay Amiantov <nikoamia@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: What can change in ways Linux handles memory when all memory
 >4G is disabled? (x86)

On 06/06/2014 05:06 PM, Nikolay Amiantov wrote:
> 
> I've played a bit with this theory in mind and found a very
> interesting thing -- when I reserve all memory upper than 4G with
> "memmap" kernel option ("memmap=99G$0x100000000"), everything works!
> Also, I've written a small utility that fills memory with zeros using
> /dev/mem and then checks it. I've checked reserved memory with it, and
> it appears that no memory in that region is corrupted at all, which is
> even more strange. I suspect that somehow when nvidia is enabled
> I/O-mapped memory regions are corrupted, and only when upper memory is
> not enabled. Also, memory map does not differ apart from missing last
> big chunk of memory with and without "memmap", and with Windows, too.
> If I enable even small chunk of "upper" memory (e.g.,
> 0x270000000-0x280000000), there are usual crashes.
> 
> Long story short: I'm interested how memory management can differ when
> this "upper" memory regions are enabled?
> 

This would point either to an iommu problem, or a problem in the driver
where addresses somehow get truncated to 32 bits.  Since this is a
graphics driver it is extremely complex, and subtle problems could be
buried somewhere inside it.  The fact that you can trigger it without a
driver would point to that kind of problem inside the firmware.

	-hpa


--
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/