Re: [Xen-devel] [PATCH v3] x86: allow 64-bit PV guest kernels to suppress user mode exposure of M2P

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.04.15 at 13:18, <tim@xxxxxxx> wrote:
> At 15:31 +0100 on 24 Apr (1429889471), Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -1435,6 +1435,14 @@ void sh_install_xen_entries_in_l4(struct
>>          shadow_l4e_from_mfn(page_to_mfn(d->arch.perdomain_l3_pg),
>>                              __PAGE_HYPERVISOR);
>>  
>> +    if ( !shadow_mode_refcounts(d) && !is_pv_32on64_domain(d) &&
> 
> I think the right check here is !shadow_mode_external(d), i.e. that
> this l4e is a mapping of the M2P and not some guest-controlled mapping.

Done. As before I'm most of the time uncertain which one to use
and hence simply matched it with the paging_mode_refcounts() use
elsewhere in the patch (which you approved already).

>> +         !VM_ASSIST(d, m2p_strict) )
>> +    {
>> +        /* zap_ro_mpt(mfn_x(sl4mfn)); */
>> +        sl4e[shadow_l4_table_offset(RO_MPT_VIRT_START)] = 
>> shadow_l4e_empty();
>> +        zap_ro_mpt(mfn_x(gl4mfn));
> 
> Here and below -- shouldn't the existing PV paths be taking care of
> zapping/filling the guest pagetable before we get here?  It doesn't
> seem right for shadow pagetable code to be making this kind of change
> - especially in a mapping that's not actually "shadowed" per se.

Right, and I actually wasn't sure - I added them just to be on the
safe side and had meant to try without, but then forgot. Will do so
now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel