Re: [Xen-devel] update_runstate_area and Linux KPTI

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/03/18 15:57, Julien Grall wrote:
> Hi,
>
> 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
improvement.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel