linux-kernel - [PATCH] Fix VMI crash on boot in 2.6.27+ kernels

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]

Message-Id: <1228870222.8766.15.camel@bodhitayantram.eng.vmware.com>
Date:	Tue, 09 Dec 2008 16:50:21 -0800
From:	Zachary Amsden <zach@...are.com>
To:	norman@...backs.co.uk,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Yinghai Lu <yhlu.kernel@...il.com>, mingo <mingo@...e.hu>,
	Greg KH <gregkh@...e.de>,
	Alok Kataria <alokkataria1@...il.com>,
	Bruno Prémont <"bruno .premont"@restena.lu>,
	xl@...igned.net, dsd@...too.org
Subject: [PATCH] Fix VMI crash on boot in 2.6.27+ kernels

Patches backported into 2.6.27.4 caused a regression with VMI kernels
running on VMware which ends in a page fault during boot.  I have a fix
which still allows DMI checks to be done early.

VMI initialiation can relocate the fixmap, causing early_ioremap
to malfunction if it is initialized before the relocation.  The
ioremap area is low enough in virtual address space that no actual
collision occurs, however, because the pagetables for it were not
allocated under VMI mode, the pagetable updates are dropped by
the hypervisor as irrelevant, resulting in a crash on boot.

The best fix is perhaps to move early_ioremap_init() after vmi_init().
The only things done before VMI init are basic memory access, things
like collating the memory map, collecting boot CPUID capabilities, and
parsing the early command line options... which vmi_init needs.

Since this went back into 2.6.27, it needs to go to both 2.6.28 and
eventually to stable.  I didn't add any comments or anything as there
could be some debate what the proper ordering should be.  In case that
becomes an interesting discussion, there are two relevant facts in git
today:

1) no clients of early_ioremap occur before DMI.
2) VMI requires access to early boot params.

If any can suggest a better ordering, I am certainly open to that as
well.

Thanks,

Zach

View attachment "x86-vmi-boot-ioremap-fix.patch" of type "text/x-patch" (1003 bytes)