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:	Wed, 13 Nov 2013 13:14:53 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vivek Goyal <vgoyal@...hat.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
CC:	Kexec Mailing List <kexec@...ts.infradead.org>,
	Baoquan He <bhe@...hat.com>, WANG Chao <chaowang@...hat.com>,
	Dave Young <dyoung@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: /proc/vmcore mmap() failure issue

On 11/13/2013 01:04 PM, Vivek Goyal wrote:
> [CC hpa ]
> 
> And this issue brings me to the question that why do we allow sytem RAM
> ranges which do not start on page boundary or do not end on page boundary. 
> Can't we truncate the BIOS reported RAM ranges in such a way so that
> they start and end at PAGE boundary and rest of the kernel will never see
> unaligned portion of RAM and this will make life so much simpler for
> other tools.
> 

That is a bit of a headache for doing in the memblock space.  We do, in
fact, truncate partial pages, but later in the game.  It is possible we
should push that sooner in the stack.  The fact that it makes into the
rbtrees is fishy, but it also makes me wonder if we're doing something
totally stupid with regards to the memory mappings -- if this means
we're mapping ACPI data as noncacheable, that is not just a performance
problem but just plain wrong.  I don't even think the MTRRs can
represent different caching attributes for different parts of a page, so
this is something that we are doing.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ