linux-kernel - [BUG] kernel 4.7 + Xen on UEFI boot crash. patch ID'd & tested, just need to verify & get it into upstream

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

Message-Id: <1470326515.4029967.686078721.338EDF9E@webmail.messagingengine.com>
Date:	Thu, 04 Aug 2016 09:01:55 -0700
From:	lists@...-mail.com
To:	linux-kernel@...r.kernel.org
Subject: [BUG] kernel 4.7 + Xen on UEFI boot crash.  patch ID'd & tested,
 just need to verify & get it into upstream

I'm running kernel 4.7/stable.

It's installed from Opensuse packages atm.

Using the current kernel causes a crash when booting Xen 4.7 on UEFI.  Referenced in this now ridiculously-long thread

	https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg02758.html

In hunting down the problem, this specific code was asked about @ 'xen-devel' ML,

	@ https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg02928.html

		While I see that you're running linux-4.7 could you please double-check
		that it has the following:

		commit 55f1ea15216a5a14c96738bd5284100a00ffa9dc
		Author: Vitaly Kuznetsov <vkuznets@...xxxxxxx>
		Date:   Tue May 31 11:23:43 2016 +0100

		    efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps

A patch to the patch was proposed @ 'xen-devel' ML,

	https://lists.xen.org/archives/html/xen-devel/2016-08/msg00399.html

It seems to fix the problem.  Boot to Xen with kernel 4.7 no longer crashes.

But then THAT patched patch was questioned @ 'opensuse-kernel' ML

	https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00747.html

I'd just like to get to a correct fix & get it into upstream kernel, since that is what I'm told we need to wait for to get packages from the distro that have the patch & work.

Since it seems it IS a kernel problem, I was hoping someone here could help shortcircuit this back & forth between projects and get the fix into kernel code.

Thanks.