Re: [Xen-devel] [PVH]: Help: msi.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.12.12 at 02:43, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 12 Dec 2012 17:15:23 -0800
> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> 
>> On Tue, 11 Dec 2012 12:10:19 +0000
>> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> 
>> > On Tue, 11 Dec 2012, Mukesh Rathor wrote:
>> > > On Mon, 10 Dec 2012 09:43:34 +0000
>> > > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> > That's strange because AFAIK Linux is never editing the MSI-X
>> > entries directly: give a look at
>> > arch/x86/pci/xen.c:xen_initdom_setup_msi_irqs, Linux only remaps
>> > MSIs into pirqs using hypercalls. Xen should be the only one to
>> > touch the real MSI-X table.
>> 
>> So, this is what's happening. The side effect of :
>> 
>>         if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
>>                                 dev->msix_table.last) )
>>             WARN();
>>         if ( rangeset_add_range(mmio_ro_ranges, dev->msix_pba.first,
>>                                 dev->msix_pba.last) )
>>             WARN();
>> 
>> in msix_capability_init() in xen is that the dom0 EPT entries that
>> I've mapped are going from RW to read only. Then when dom0 accesses
>> it, I get EPT violation. In case of pure PV, the PTE entry to access
>> the iomem is RW, and the above rangeset adding doesn't affect it. I
>> don't understand why? Looking into that now...

As far as I was able to tell back at the time when I implemented
this, existing code shouldn't have mappings for these tables in
place at the time these ranges get added here. But I noted in
the patch description that this is a potential issue (and may need
fixing if deemed severe enough - back then, apparently nobody
really cared, perhaps largely because passthrough to PV guests
isn't considered fully secure anyway).

Now - did that change? I.e. can you describe where the mappings
come from that cause the problem here? Because if that is
possible even with non-hostile code, that might warrant properly
dealing with that, even if pretty involved (I don't think there's a
way to find all mappings of a given page other than a brute force
scan of all L1 page tables the domain currently has).

> Ah, it's coming from:
> 
> ept_p2m_type_to_flags(): 
>    case p2m_mmio_direct:
>        entry->r = entry->x = 1;
>        entry->w = !rangeset_contains_singleton(mmio_ro_ranges, entry->mfn);
> 
> I suppose, the best fix would be to add a check here for dom0 and let it
> have w access?

No, absolutely not. Nor would that help with the same issue in a
DomU.

Jan


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