RE: [PATCH] VMX: use a single, global APIC access page

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Monday, March 1, 2021 5:59 PM
> 
> On 01.03.2021 09:30, Tian, Kevin wrote:
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: Monday, March 1, 2021 4:16 PM
> >>
> >> On 01.03.2021 03:18, Tian, Kevin wrote:
> >>>> From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >>>> Sent: Thursday, February 11, 2021 8:27 PM
> >>>>
> >>>> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
> >>>>> On 11.02.2021 12:16, Roger Pau Monné wrote:
> >>>>>> On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
> >>>>>>> On 11.02.2021 09:45, Roger Pau Monné wrote:
> >>>>>>>> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
> >>>>>>>>> --- a/xen/include/asm-x86/p2m.h
> >>>>>>>>> +++ b/xen/include/asm-x86/p2m.h
> >>>>>>>>> @@ -935,6 +935,9 @@ static inline unsigned int p2m_get_iommu
> >>>>>>>>>          flags = IOMMUF_readable;
> >>>>>>>>>          if ( !rangeset_contains_singleton(mmio_ro_ranges,
> >> mfn_x(mfn)) )
> >>>>>>>>>              flags |= IOMMUF_writable;
> >>>>>>>>> +        /* VMX'es APIC access page is global and hence has no
> owner.
> >>>> */
> >>>>>>>>> +        if ( mfn_valid(mfn)
> && !page_get_owner(mfn_to_page(mfn)) )
> >>>>>>>>> +            flags = 0;
> >>>>>>>>
> >>>>>>>> Is it fine to have this page accessible to devices if the page tables
> >>>>>>>> are shared between the CPU and the IOMMU?
> >>>>>>>
> >>>>>>> No, it's not, but what do you do? As said elsewhere, devices
> >>>>>>> gaining more access than is helpful is the price we pay for
> >>>>>>> being able to share page tables. But ...
> >>>>>>
> >>>>>> I'm concerned about allowing devices to write to this shared page, as
> >>>>>> could be used as an unintended way to exchange information
> between
> >>>>>> domains?
> >>>>>
> >>>>> Well, such an abuse would be possible, but it wouldn't be part
> >>>>> of an ABI and hence could break at any time. Similarly I
> >>>>> wouldn't consider it an information leak if a guest abused
> >>>>> this.
> >>>>
> >>>> Hm, I'm kind of worried about having such shared page accessible to
> >>>> guests. Could Intel confirm whether pages in the 0xFEExxxxx range are
> >>>> accessible to devices in any way when using IOMMU shared page
> >>>> tables?
> >>>
> >>> 0xFEExxxxx range is special. Requests to this range are not subject to
> >>> DMA remapping (even if a valid mapping for this range exists in the
> >>> IOMMU page table). And this special treatment is true regardless of
> >>> whether interrupt remapping is enabled (which comes only after an
> >>> interrupt message to this range is recognized).
> >>
> >> For my/our education, could you outline what happens to device
> >> accesses to that range when interrupt remapping is off? And
> >> perhaps also what happens to accesses to this range that don't
> >> match the pattern of an MSI initiation (dword write)? I don't
> >> think I've been able to spot anything to this effect in the docs.
> >>
> >
> > In VT-d spec "3.14 Handling Requests to Interrupt Address Range"
> > --
> > On Intel® architecture platforms, physical address range 0xFEEx_xxxx is
> > designated as the interrupt address range. Requests without PASID to
> > this range are not subjected to DMA remapping (even if translation
> > structures specify a mapping for this range).
> > --
> > The following types of requests to this range are illegal requests.
> > They are blocked and reported as Interrupt Remapping faults.
> > • Read requests without PASID that are not ZLR.
> > • Atomics requests without PASID.
> > • Non-DWORD length write requests without PASID.
> > --
> 
> Ah, I see. That's (according to the change bars) a relatively recent
> addition. So the above clarifies things for the !PASID case. Am I
> interpreting
> 
> "Requests-with-PASID with input address in range 0xFEEx_xxxx are
>  translated normally like any other request-with-PASID through
>  DMA-remapping hardware. However, if such a request is processed
>  using pass-through translation, it will be blocked as described
>  in the paragraph below.
> 
>  Software must not program paging-structure entries to remap any
>  address to the interrupt address range. Untranslated requests and
>  translation requests that result in an address in the interrupt
>  range will be blocked with condition code LGN.4 or SGN.8.
>  Translated requests with an address in the interrupt address
>  range are treated as Unsupported Request (UR)."
> 
> right in that _with_ PASID translation entries for this range would
> still be used, so long as they translate to an area outside of the
> FEExxxxx range? If so this would mean that with PASID (whenever we

yes

> get to enabling this mode of operation) we'd need to avoid sharing
> page tables, and we'd need to suppress mirroring of EPT insertions
> for this range in the IOMMU page tables. (All of this independent
> of the particular choice of the APIC access page.)
> 

Or you can still share page tables as long as no DMA will target at
this range (which should be the normal case and any inadvertent
or malicious attempt is blocked anyway).


Thanks
Kevin