On 22/02/2021 10:27, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least for 32-bit PV
> guests. To avoid extra is_hvm_*() conditionals, use the alternative VA
> uniformly.
>
> While this could be conditionalized upon CONFIG_PV32 &&
> CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS, omitting such extra conditionals
> keeps the code more legible imo.
>
> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against
> speculative abuse")
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1727,6 +1727,11 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
> (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots -
> l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
> }
> +
> + /* Slot 511: Per-domain mappings mirror. */
> + if ( !is_pv_64bit_domain(d) )
> + l4t[l4_table_offset(PERDOMAIN2_VIRT_START)] =
> + l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
This virtual address is inside the extended directmap. You're going to
need to rearrange more things than just this, to make it safe.
While largely a theoretical risk as far as the directmap goes, there is
now a rather higher risk of colliding with the ERR_PTR() range. Its bad
enough this infrastructure is inherently unsafe with 64bit PV guests,
~Andrew
