[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3] AMD/intremap: Prevent use of per-device vector maps until irq logic is fixed



>>> On 10.06.13 at 14:25, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 04.06.13 at 18:38, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> XSA-36 changed the default vector map mode from global to per-device.  This 
>> is
>> because a global vector map does not prevent one PCI device from 
>> impersonating
>> another and launching a DoS on the system.
>> 
>> However, the per-device vector map logic is broken for devices with multiple
>> MSI-X vectors, which can either result in a failed ASSERT() or misprogramming
>> of a guests interrupt remapping tables.  The core problem is not trivial to
>> fix.
>> 
>> In an effort to get AMD systems back to a non-regressed state, introduce a 
>> new
>> type of vector map called per-device-global.  This uses per-device vector 
>> maps
>> in the IOMMU, but uses a single used_vector map for the core IRQ logic.
>> 
>> This patch is intended to be removed as soon as the per-device logic is fixed
>> correctly.
>> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 
> Suravee, Jacob,
> 
> no opinion on this at all? I've been talked into considering this
> acceptable (with a small coding style fixup, and with the question on
> the usefulness of the final warning message - imo redundant with the
> immediately preceding message that is being left untouched), with
> the strict expectation that this would get reverted right away after
> 4.3, with the multi-vector MSI series being the real fix to this
> (presumably allowing to drop the vector map stuff altogether).

as we're running out of time with this for 4.3, I'm inclined to
treat the lack of a response from you as a "don't care, do what
you want" and commit the patch without an ack. As I'm in no
way happy about that, I'd like to give you a last chance to ack or
nack the patch, or comment on it in other ways. Early next week,
if no response from either of you arrived, I'm going to commit it
with a yet to be invented tag stating the situation.

Jan

>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -223,8 +223,19 @@ int __init amd_iov_detect(void)
>>      {
>>          if ( amd_iommu_perdev_intremap )
>>          {
>> -            printk("AMD-Vi: Enabling per-device vector maps\n");
>> -            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_PERDEV;
>> +            /* Per-device vector map logic is broken for devices with 
> multiple
>> +             * MSI-X interrupts (and would also be for multiple MSI, if Xen
>> +             * supported it).
>> +             *
>> +             * Until this is fixed, use global vector tables as far as the 
> irq
>> +             * logic is concerned to avoid the buggy behaviour of per-device
>> +             * maps in map_domain_pirq(), and use per-device tables as far 
> as
>> +             * intremap code is concerned to avoid the security issue.
>> +             */
>> +            printk(XENLOG_WARNING "AMD-Vi BUG: per-device vector map logic 
>> is 
> broken.  "
>> +                   "Using per-device-global maps instead until a fix is 
> found\n");
>> +
>> +            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_GLOBAL;
>>          }
>>          else
>>          {
>> @@ -235,6 +246,12 @@ int __init amd_iov_detect(void)
>>      else
>>      {
>>          printk("AMD-Vi: Not overriding irq_vector_map setting\n");
>> +
>> +        if ( opt_irq_vector_map != OPT_IRQ_VECTOR_MAP_GLOBAL )
>> +        {
>> +            printk(XENLOG_WARNING "AMD-Vi BUG: per-device vector map logic 
>> is 
> broken.  "
>> +                   "Use irq_vector_map=global to work around.");
>> +        }
>>      }
>>      if ( !amd_iommu_perdev_intremap )
>>          printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table 
>> is 
> not recommended (see XSA-36)!\n");
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.