linux-kernel - Kexec query about what makes sure control pages/page tables are not overwritten

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-next>] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 15:53:41 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Kexec query about what makes sure control pages/page tables are not
 overwritten

Hi,

I am staring at control page allocation logic in case of kdump and
wondering what makes sure that these pages are not overwritten by 
next kernel.

I see that for 64bit entry, control pages have the page tables needed
for second kernel. In case of crash these pages from from crash kernel
reserved region. Page allocator is very simple and that is start from
lowest crash reserved range and move higher and allocate first available
page which is not allocated to segments. What makes sure that these pages
are not overwritten by second kernel.

I guess it becomes a general bootloader question. How do we make sure
bootloader prepared page tables/gdt will not be overwritten by kernel
(till kernel sets up its own page tables and gdt) and how should we do the
allocation and placement.

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