On 02/03/18 15:57, Julien Grall wrote:
> While I was looking at some unrelated problem with Xen ARM P2M code, I
> noticed that the function update_runstate_area is using guest virtual
> address to update the vCPU runstate. That function will be called when
> context switch to a vCPU. However, that vCPU may run in userspace
> context. When KPTI (kernel page table isolation) is used,
> In the best case, that address is not mapped into the page-table
> currently used. Xen will not be able to update the region.
> In the worst case, that address is mapped to a different region and
> Xen will corrupt some bits of the memory.
> The code looks fundamentally wrong on Arm, I am entirely not sure
> about x86.
> It look like to me that Xen should always use the guest physical
> address and therefore translate the virtual address to a physical one
> in VCPUOP_register_runstate_memory_area. So only the physical address
> will be used in update_runstate_area making the function much safer.
> Any opinion on this approach?
All the Xen interfaces like this built upon linear (virtual) addresses
are fundamentally wrong, but that horse has bolted.
On the x86 side, we've got a gross hack where we try and ignore
pagefaults, leaving a note to come back and try again later. It gets
even more complicated with SMAP (PAN on ARM, iirc).
The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
choosing, and the guests pagetable/permissions state at an instantaneous
moment don't matter.
If you've got time to do this, then please do. It will be a definite
Xen-devel mailing list