Re: [PATCH] kvm: deassign irqs in reset path

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

On 2012-03-30 23:09, Alex Williamson wrote:
> On Fri, 2012-03-30 at 22:35 +0200, Jan Kiszka wrote:
>> On 2012-03-30 22:31, Jason Baron wrote:
>>> On Fri, Mar 30, 2012 at 10:18:31PM +0200, Jan Kiszka wrote:
>>>>>>> The root cause of the problem is that the 'reset_assigned_device()' code
>>>>>>> first writes a 0 to the command register. Then, when qemu subsequently does
>>>>>>> a kvm_deassign_irq() (called by assign_irq(), in the system_reset path),
>>>>>>> the kernel ends up calling '__msix_mask_irq()', which performs a write to
>>>>>>> the memory mapped msi vector space. Since, we've explicitly told the device
>>>>>>> to disallow mmio access (via the 0 write to the command register), we end
>>>>>>> up with the above 'Unsupported Request'.
>>>>>>>
>>>>>>> The fix here is to first call kvm_deassign_irq(), before doing the reset,
>>>>>>
>>>>>> s/fix/workaround/. This is a kernel bug if userspace can crash the
>>>>>> system like this, no? Let's fix the kernel first and then look at what
>>>>>> needs to be changed here.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>
>>>>> But don't I need special privalege to run the device assignment bits?
>>>>
>>>> Yes, but even that might be moderated by a management component like
>>>> libvirt.
>>>>
>>>>> For example, this crash is precipitated by a write of '0' to the pci
>>>>> device config register from userspace. Surely, not every is allowed to
>>>>> do that write. So it seems to me, that this patch is in keeping with the
>>>>> current model of how things work.
>>>>
>>>> No user should needlessly be able to crash the host by issuing valid
>>>> commands in a special order.
>>>>
>>>> Jan
>>>>
>>>
>>> Right, but as I see device-assign.c, we are essentially programming the
>>> pci device directly from userspace. Put another way, the kernel could
>>> crash the system if it programmed a pci device in the wrong order. So I
>>> don't see how this is different. But maybe I'm misunderstanding the
>>> model here?
>>
>> The model is that the KVM device assignment subsystem in the kernel (or
>> vfio in the future) + the IOMMU confine what userspace (not the qemu
>> guest) can do with the device and prevent that any harm is caused to the
>> system. There might be practical holes in this model, but this is still
>> what we are striving for.
> 
> Jan,
> 
> It's possible to cause this same crash w/o device assignment involved.
> Use setpci to zero the command register, then set smp_affinity on the
> device using MSI-X.  It's the right thing to do for qemu reset to return
> device interrupts to a known state, even if it does just happen to be a
> workaround for this problem.

Looks like the right thing is first of all to catch hardware errors of
an untrusted device and handle them more gracefully than panicing the
whole system. I suppose the very same panic can be triggered by writing
to other MMIO bars after fiddling with the command register. And as we
are passing the command register through, this is even guest
triggerable, no? Can failing PIO access cause such panics as well?

>  Given that we're using a generic interface
> for config space, I'm not sure how practical it is to start arbitrarily
> picking certain things as bad and making them inaccessible (there are
> plenty of targets in PCI config space on x86).  Thanks,

This patch provides band-aid for a single symptom. But we rather need
cure for the disease you discovered.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]