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 Xenfirstname.lastname@example.org https://lists.xenproject.org/mailman/listinfo/xen-devel