On 22/02/2021 14:22, Jan Beulich wrote:
> 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 <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.
> 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.
map_domain_page() will blindly hand this virtual address if an
appropriate mfn is passed, because there are no suitability checks.
The error handling isn't great, but at least any attempt to use that
pointer would fault, which is now no longer the case.
LA57 machines can have RAM or NVDIMMs in a range which will tickle this
bug. In fact, they can have MFNs which would wrap around 0 into guest
space.
~Andrew
