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  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]
Date:   Tue, 24 Jan 2017 14:15:05 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Cc:     marc.zyngier@....com, will.deacon@....com,
        linux-arm-kernel@...ts.infradead.org, linuxarm@...wei.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        john.garry@...wei.com, guohanjun@...wei.com, robin.murphy@....com
Subject: Re: [RFC 2/4] irqchip, gicv3-its:Workaround for HiSilicon erratum
 161010801

On Tue, Jan 24, 2017 at 01:47:57PM +0000, Shameerali Kolothum Thodi wrote:
> The HiSilicon erratum 161010801 describes the limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> 
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the
> MSI payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.

Do you mean that the PCIe root controller looking at the (virtual)
addresses of DMA and comparing these against the (physical) address of
the ITS in order to determine if a write is an MSI?

I can't see anything in this patch specifically enabling bypass for
MSIs. Do writes to the ITS (physical) address always bypass the SMMU,
and go straight to the ITS? Regardless of translation applied to other
DMA?

It sounds like this will have severe implications for virtualization.

> Also these platforms doesn't have a proper IIDR
> register to use the existing IIDR based quirk mechanism.

What exactly is wrong with the IIDR on these platforms? That sounds like
an erratum as of itself.

What precise value do reads of the IIDR return? Or do reads result in
other erroneous behaviour?

Thanks,
Mark.

Powered by blists - more mailing lists