linux-kernel - Re: [PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL85gmBB=U_4jkChKwfZGPQR0zeoZ4=hg7e6HMnu-DS0u1-Wsg@mail.gmail.com>
Date:   Fri, 21 Jul 2017 13:20:18 -0700
From:   Feng Kan <fkan@....com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

On Thu, Jul 20, 2017 at 3:22 PM, Alex Williamson
<alex.williamson@...hat.com> wrote:
> On Wed, 19 Jul 2017 17:46:51 -0700
> Feng Kan <fkan@....com> wrote:
>
>> The APM X-Gene PCIe root port does not support ACS at this point.
>> However, the hw provides isolation and source validation through
>> the SMMU. Turn on ACS but disable all the peer to peer features.
>>
>> Signed-off-by: Feng Kan <fkan@....com>
>> ---
>>  drivers/pci/quirks.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 085fb78..0f8f1cd 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
>>       return acs_flags ? 0 : 1;
>>  }
>>
>> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> +{
>> +     /*
>> +      * XGene root matching this quirk do not allow peer-to-peer
>> +      * transactions with others, allowing masking out these bits as if they
>> +      * were unimplemented in the ACS capability.
>> +      */
>> +     acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> +                    PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> +
>> +     return acs_flags ? 0 : 1;
>> +}
>> +
>>  /*
>>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>>   * transactions and validate bus numbers in requests, but do not provide an
>> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, u16 acs_flags)
>>       { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>>       /* Cavium ThunderX */
>>       { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> +     /* APM XGene */
>> +     { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>>       { 0 }
>>  };
>>
>
> Sorry, I'm not yet convinced there's an equivalent of SV, if a device
> spoofs a different bdf and it reaches the smmu, what prevents that from
> simply referencing the context for that alternate bdf?
Perhaps I am not understanding the question correctly. The bdf forms a
stream id which is used to provide an context. Since there is no actual
context created by an alternate bdf, the transaction would be rejected
by the SMMU.

The point of
> root port SV is to ensure that any forwarded transaction is within the
> downstream bdf range.  Thanks,
>
> Alex