linux-kernel - Re: [Xen-devel] [PATCH v4] xen PVonHVM: move 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:	Tue, 30 Oct 2012 16:45:48 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Olaf Hering" <olaf@...fle.de>
Cc:	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"xen-devel" <xen-devel@...ts.xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area

>>> On 30.10.12 at 17:30, Olaf Hering <olaf@...fle.de> wrote:
> On Tue, Oct 30, Jan Beulich wrote:
> 
>> >>> On 30.10.12 at 16:47, Olaf Hering <olaf@...fle.de> wrote:
>> > 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.
>> 
>> One thing that occurred to me only now: How is this relocation
>> of the shared info going to help with the vCPU info placement?
>> You can't undo this, nor can you re-register these areas to be
>> put in a different location (of course, both of there could be
>> implemented in the hypervisor). Yet the hypervisor writes to
>> some of these areas' fields as much as it does write to the
>> shared info structure itself.
> 
> Maybe the wording "move" is a bit misleading in this patch. 
> 
> A single "move" of the actual pfn happens during boot, that is when a
> PVonHVM enabled guest kernel does the XENMAPSPACE_shared_info operation.
> It moves the pfn of the shared info page from the location the hvmloader
> initially configured to this new pfn (0xfffff -> 0xfe700).
> Another relocation does not happen at runtime, AFAIK.
> 
> The "move" which this patch does is more a source level move in the
> sense that RESERVE_BRK (which is somewhere in the middle of RAM) is not
> used anymore. Instead a pfn in an E820_Reserved area is used, see
> xen-unstable changeset 26108:79185dcdf558 "hvmloader: Reserve
> FE700000-FE800000 in physical memory map for guest use."

And iirc you're doing this relocation because otherwise the newly
booting kernel image may get overwritten at an (from its
perspective) arbitrary location. What I'm trying to point out is
that the shared info structure is not the only thing (potentially)
inside the kernel image that might get overwritten - the relocated
(by the old kernel) vCPU info may as well. Plus I think the new
kernel has no way of relocating it a second time (including back
into the shared info structure) with how the hypervisor works at
present.

Jan

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