linux-kernel - Re: [PATCH RFC 1/4] xen PVonHVM: use E820_Reserved area for shared

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:	Mon, 4 Aug 2014 11:15:35 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	Vitaly Kuznetsov <vkuznets@...hat.com>,
	xen-devel@...ts.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Andrew Jones <drjones@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/4] xen PVonHVM: use E820_Reserved area for
 shared_info

On Mon, Jul 28, 2014 at 02:33:06PM +0100, David Vrabel wrote:
> On 15/07/14 14:40, Vitaly Kuznetsov wrote:
> > From: Olaf Hering <olaf@...fle.de>
> > 
> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> > ("xen PVonHVM: move shared_info to MMIO before kexec").
> > 
> > Currently kexec in a PVonHVM guest fails with a triple fault because the
> > new kernel overwrites the shared info page. The exact failure depends on
> > the size of the kernel image. This patch moves the pfn from RAM into an
> > E820 reserved memory area.
> > 
> > The pfn containing the shared_info is located somewhere in RAM. This will
> > cause trouble if the current kernel is doing a kexec boot into a new
> > kernel. The new kernel (and its startup code) can not know where the pfn
> > is, so it can not reserve the page. The hypervisor will continue to update
> > the pfn, and as a result memory corruption occours in the new kernel.
> > 
> > The toolstack marks the memory area FC000000-FFFFFFFF as reserved in the
> > E820 map. Within that range newer toolstacks (4.3+) will keep 1MB
> > starting from FE700000 as reserved for guest use. Older Xen4 toolstacks
> > will usually not allocate areas up to FE700000, so FE700000 is expected
> > to work also with older toolstacks.
> > 
> > In Xen3 there is no reserved area at a fixed location. If the guest is
> > started on such old hosts the shared_info page will be placed in RAM. As
> > a result kexec can not be used.
> > 
> > Signed-off-by: Olaf Hering <olaf@...fle.de>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > (cherry picked from commit 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f)
> 
> Is this a useful commit to give?  Isn't it one of Konrad's random trees?

Actually it is from upstream. That patch was reverted at certain point.

Perhaps just mention that it was added in, then reverted, and now after
a year or so, added back in with the fix.
--
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/