OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [PATCH v3] Add virtio-iommu device specification


On 15/05/2019 06:30, Tian, Kevin wrote:
>> From: Tian, Kevin
>> Sent: Wednesday, May 15, 2019 1:08 PM
>> To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>; Michael S.
>> Tsirkin <mst@redhat.com>
>>>
>>>
>>>>>>> +\begin{description}
>>>>>>> +  \item[VIRTIO_IOMMU_RESV_MEM_T_RESERVED (0)]
>>>>>>> +    Accesses to virtual addresses in this region have undefined
>> behavior.
>>>>>>
>>>>>> undefined?  how can platforms with such a property coexist with
>>> untrusted
>>>>>> devices?
>>>>>
>>>>> It is "undefined" because I can't enumerate all cases (don't know about
>>>>> all of them). This would contain for example the RMRR regions of VT-d
>>>>> (the BIOS reserving some DMA regions for itself), regions allocated for
>>>>> host-managed MSIs on arm platforms, and some PCI bridge windows
>>>>> (although they removed those from the Linux resv regions recently, not
>>>>> certain why). Ideally we wouldn't have any, but some special cases make
>>>>> it necessary.
> 
> +Alex.
> 
> Actually I don't think RMRR is right example here (sorry if it's my input in
> our previous discussion). There was concern on RMRR providing a shared
> memory region between device and platform controller, thus may cause
> isolation issue:
> 	https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf
> 
> So the basic policy for devices with RMRR is, excluding them from device
> assignment, except for Intel GPU and USB. The latter two has well-understood
> behavior on RMRR, thus they can be safely assigned with RMRR ignored
> (i.e. RMRR region can be reused as valid IOVA region).  

Ah I see, seems like a good policy.

> As I commented below, I think it's safe to describe reserved region behavior
> as either succeed with undefined behavior (e.g. in ARM MSI doorbell case, 
> where a spurious interrupt on allocated doorbell for this device is triggered 
> instead of desired DMA access), or cause vIOMMU unrecoverable fault due 
> to invalid mappings. An untrusted device can never use reserved region to 
> escape since physically IOMMU only contains verified mapping to granted
> resource (MSI) or nothing.

Yes, I will add that as a requirement in next version: reserved regions
are okay as long as they don't allow a device to escape isolation.
Finding the right wording without being too vague is a bit tough for
this one.

>>>>>
>>>>> In general having reserved regions is incompatible with untrusted
>>>>> devices, and in some cases incompatible with untrusted guests. But
>>>>> choosing the policy about which devices to present to guest is up to the
>>>>> platform. The host knows what the resv regions are used for, and if they
>>>>> are safe enough. The guest just need to knows what to avoid.
>>>>
>>>> Yes but ... if you trust driver and device then what's the
>>>> point of the iommu?
>>>
>>> Improving memory allocation. The guest can do scatter-gather for large
>>> buffers, instead of allocating big contiguous chunks of guest-physical
>>> addresses. And with device pass-through, any memory used for DMA has to
>>> be pinned (since devices generally don't support page faults). So when
>>> assigning an endpoint to a guest, without a vIOMMU all of the guest
>>> memory has to be pinned upfront. With an IOMMU only the memory that
>> will
>>> actually be used for DMA is pinned.
>>
>> I'd not vote using current vIOMMU just for avoiding pin instead of for
>> isolation purpose... the map/unmap overhead is high except you only
>> talking about static mapping e.g. in guest user space driver (e.g. DPDK)
>> (but then it's actually for isolation purpose between user and kernel).
>>  btw we are working on a lighter-weight approach (aim <5% perf drop
>> for most cases) while allowing host to fully introspect guest DMA activities.
>> Likely we'll introduce a new virtio-iommu capability for this purpose,
>> instead of using current MAP/UNMAP primitives. Stay tuned and we'll
>> send out RFC soon once getting good result. :-)

Sounds great, I'd like to hear more about this. I also have some drafts
for performance improvement and SVA, but haven't found time to progress
on that in a while. For SVA however, introspection seems nearly
impossible (on Arm the host may not even see invalidation commands from
the guest).

Thanks,
Jean

>>
>> And I don't think having reserved regions is incompatible with untrusted
>> devices. Favoring reserved region is a functional requirement so guest
>> driver can operate assigned device in a good shape. Violating reserved
>> region requirement (e.g. map guest memory page to reserved region) just
>> means device access to this page doesn't provide desired behavior, since
>> host will always guarantee safe behavior in physical IOMMU on those
>> regions:
>>
>> - it is either mapped to fixed resource (e.g ARM MSI doorbell)
>> which is associated with this device and thus safe
>> - or map to nothing
>>
>> I don't think architecturally we break any isolation implication on
>> IOMMU here.
>>
>> Thanks
>> Kevin



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]