On Wed, Jan 28, 2015 at 8:51 AM, Marc Zyngier <[email protected]> wrote:
> pcibios_update_irq writes an irq number into the config space
> of a given PCI device, but ignores the fact that this number
> is a virtual interrupt number, which might be a very different
> value from what the underlying hardware is using.
>
> The obvious fix is to fetch the HW interrupt number from the
> corresponding irq_data structure. This is slightly complicated
> by the fact that this interrupt might be services by a stacked
> domain.
>
> This has been tested on KVM with kvmtool.
>
> Reported-by: Lorenzo Pieralisi <[email protected]>
> Tested-by: Andre Przywara <[email protected]>
> Signed-off-by: Marc Zyngier <[email protected]>
Jiang, are you OK with this patch as-is now, since it isn't used on x86?
Marc, Lorenzo, I assume this actually fixes a bug. Can we get any
more details about what happens when you hit the bug, and how you
reproduced it (what platform, driver, etc.)?
Bjorn
> ---
> drivers/pci/setup-irq.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
> index 4e2d595..828cbc9 100644
> --- a/drivers/pci/setup-irq.c
> +++ b/drivers/pci/setup-irq.c
> @@ -15,11 +15,19 @@
> #include <linux/errno.h>
> #include <linux/ioport.h>
> #include <linux/cache.h>
> +#include <linux/irq.h>
>
> void __weak pcibios_update_irq(struct pci_dev *dev, int irq)
> {
> - dev_dbg(&dev->dev, "assigning IRQ %02d\n", irq);
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
> + struct irq_data *d;
> +
> + d = irq_get_irq_data(irq);
> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
> + while (d->parent_data)
> + d = d->parent_data;
> +#endif
> + dev_dbg(&dev->dev, "assigning IRQ %02ld\n", d->hwirq);
> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, d->hwirq);
> }
>
> static void pdev_fixup_irq(struct pci_dev *dev,
> --
> 2.1.4
>
On 2015/2/2 23:57, Bjorn Helgaas wrote:
> On Wed, Jan 28, 2015 at 8:51 AM, Marc Zyngier <[email protected]> wrote:
>> pcibios_update_irq writes an irq number into the config space
>> of a given PCI device, but ignores the fact that this number
>> is a virtual interrupt number, which might be a very different
>> value from what the underlying hardware is using.
>>
>> The obvious fix is to fetch the HW interrupt number from the
>> corresponding irq_data structure. This is slightly complicated
>> by the fact that this interrupt might be services by a stacked
>> domain.
>>
>> This has been tested on KVM with kvmtool.
>>
>> Reported-by: Lorenzo Pieralisi <[email protected]>
>> Tested-by: Andre Przywara <[email protected]>
>> Signed-off-by: Marc Zyngier <[email protected]>
>
> Jiang, are you OK with this patch as-is now, since it isn't used on x86?
Sure, I'm OK. I missed the point that it's not used on x86 at all
in previous review.
>
> Marc, Lorenzo, I assume this actually fixes a bug. Can we get any
> more details about what happens when you hit the bug, and how you
> reproduced it (what platform, driver, etc.)?
>
> Bjorn
>
>> ---
>> drivers/pci/setup-irq.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
>> index 4e2d595..828cbc9 100644
>> --- a/drivers/pci/setup-irq.c
>> +++ b/drivers/pci/setup-irq.c
>> @@ -15,11 +15,19 @@
>> #include <linux/errno.h>
>> #include <linux/ioport.h>
>> #include <linux/cache.h>
>> +#include <linux/irq.h>
>>
>> void __weak pcibios_update_irq(struct pci_dev *dev, int irq)
>> {
>> - dev_dbg(&dev->dev, "assigning IRQ %02d\n", irq);
>> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
>> + struct irq_data *d;
>> +
>> + d = irq_get_irq_data(irq);
>> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
>> + while (d->parent_data)
>> + d = d->parent_data;
>> +#endif
>> + dev_dbg(&dev->dev, "assigning IRQ %02ld\n", d->hwirq);
>> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, d->hwirq);
>> }
>>
>> static void pdev_fixup_irq(struct pci_dev *dev,
>> --
>> 2.1.4
>>
On 02/02/15 15:57, Bjorn Helgaas wrote:
> On Wed, Jan 28, 2015 at 8:51 AM, Marc Zyngier <[email protected]> wrote:
>> pcibios_update_irq writes an irq number into the config space
>> of a given PCI device, but ignores the fact that this number
>> is a virtual interrupt number, which might be a very different
>> value from what the underlying hardware is using.
>>
>> The obvious fix is to fetch the HW interrupt number from the
>> corresponding irq_data structure. This is slightly complicated
>> by the fact that this interrupt might be services by a stacked
>> domain.
>>
>> This has been tested on KVM with kvmtool.
>>
>> Reported-by: Lorenzo Pieralisi <[email protected]>
>> Tested-by: Andre Przywara <[email protected]>
>> Signed-off-by: Marc Zyngier <[email protected]>
>
> Jiang, are you OK with this patch as-is now, since it isn't used on x86?
>
> Marc, Lorenzo, I assume this actually fixes a bug. Can we get any
> more details about what happens when you hit the bug, and how you
> reproduced it (what platform, driver, etc.)?
It definitely fixes a bug. This has been found by running a KVM guest
using kvmtool PCI emulation, where the following things happen:
- Guest programs a virtual (bogus) interrupt number in the PCI device
config space (virtio disk in this case)
- kvmtool uses that interrupt number as is, without any other form of
validation
- Either the injection fails (because the interrupt is out of the range
of the virtual interrupt controller) -> virtio PCI device goes dead
- or the injection succeeds because this is a valid interrupt number,
but signals an unrelated peripheral -> virtio PCI device goes dead.
This can be trivially reproduced on any ARM PCI system that requires
legacy interrupts (i.e. no MSI support), and that uses a GIC interrupt
controller. Doing it in a VM is just much more convenient.
Hope this helps,
M.
--
Jazz is not dead. It just smells funny...