On 09/30/15 21:55, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 18:26, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote:
>>>> How not virtualizing iommu forces "all or nothing" approach?
>>> Looks like you can't limit an assigned device to only access part of
>>> guest memory that belongs to a given process. Either let it access all
>>> of guest memory ("all") or don't assign the device ("nothing").
>> Ok. A question then: can u limit the assigned device to only access part of
>> the guest memory even if iommu was virtualized?
> That's exactly what an iommu does - limit the device io access to memory.
If it does - it will continue to do so with or without the patch and if
it doesn't (for any reason) it won't do it even without the patch.
So, again, the above (rhetorical) question stands. ;)
I think Avi has already explained quite in detail why security is
absolutely a non issue in regard to this patch or in regard to UIO in
general. Security has to be enforced by some other means like iommu.
>
>> How would iommu
>> virtualization change anything?
> Kernel can use an iommu to limit device access to memory of
> the controlling application.
Ok, this is obvious but what it has to do with enabling using MSI/MSI-X
interrupts support in uio_pci_generic? kernel may continue to limit the
above access with this support as well.
>
>> And why do we care about an assigned device
>> to be able to access all Guest memory?
> Because we want to be reasonably sure a kernel memory corruption
> is not a result of a bug in a userspace application.
Corrupting Guest's memory due to any SW misbehavior (including bugs) is
a non-issue by design - this is what HV and Guest machines were invented
for. So, like Avi also said, instead of trying to enforce nobody cares
about we'd rather make the developers life easier instead (by applying
the not-yet-completed patch I'm working on).
>
