[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH][4.15] x86: mirror compat argument translation area for 32-bit PV
On 22.02.2021 15:14, Andrew Cooper wrote: > 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 <jbeulich@xxxxxxxx> >> >> --- 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. No. That one covers only the range excluding the last L4 slot. > You're going to > need to rearrange more things than just this, to make it safe. I specifically picked that entry because I don't think further arrangements are needed. > 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, The ERR_PTR() range is still _far_ away from the sub-ranges we use in the per-domain area. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |