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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <839e3878-ae62-4c8b-a74b-ac4f6f060d98@app.fastmail.com>
Date: Thu, 09 Oct 2025 23:16:02 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Manivannan Sadhasivam" <mani@...nel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@...nel.org>,
 "Vincent Guittot" <vincent.guittot@...aro.org>,
 "Chester Lin" <chester62515@...il.com>,
 "Matthias Brugger" <mbrugger@...e.com>,
 "Ghennadi Procopciuc" <ghennadi.procopciuc@....nxp.com>,
 "NXP S32 Linux Team" <s32@....com>, bhelgaas@...gle.com,
 jingoohan1@...il.com,
 Krzysztof WilczyƄski <kwilczynski@...nel.org>,
 "Rob Herring" <robh@...nel.org>, krzk+dt@...nel.org,
 "Conor Dooley" <conor+dt@...nel.org>, Ionut.Vicovan@....com,
 "Larisa Grigore" <larisa.grigore@....com>,
 "Ghennadi Procopciuc" <Ghennadi.Procopciuc@....com>,
 ciprianmarian.costea@....com, "Bogdan Hamciuc" <bogdan.hamciuc@....com>,
 "Frank Li" <Frank.li@....com>, linux-arm-kernel@...ts.infradead.org,
 linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
 "Niklas Cassel" <cassel@...nel.org>
Subject: Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller

On Thu, Oct 9, 2025, at 20:47, Manivannan Sadhasivam wrote:
> On Wed, Oct 08, 2025 at 07:56:44PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 8, 2025, at 17:19, Manivannan Sadhasivam wrote:
>>
>> That is not my impression from reading the code: At least for
>> the case where both devices are on the same bridge and they
>> use map_type=PCI_P2PDMA_MAP_BUS_ADDR, I would expect the DMA
>> to use the plain PCI bus address, not going through the
>> dma-ranges+ranges translation that would apply when they are
>> on different host bridges.
>> 
>
> Right, but I don't get the overlap issue still. If the P2P client triggers a
> write to a P2P PCI address (let's assume 0x8000_0000), and if that address
> belongs to a an endpoint in a different domain, the host bridge should still
> forward it to the endpoint without triggering write to the RAM.

If 0x8000_0000 is an endpoint in a different domain, I would expect the
DMA transfer to go to the RAM at that address since the DMA has to leave
the PCI host bridge upstream by following its inbound windows.

This is not the problem I'm talking about though, since cross-domain
P2P is not particularly well-defined.

> Atleast, I don't see any concern from the outbound memory translation point of
> view.
>
> Please let me know if there is any gap in my understanding.

To clarify: I don't think that programming the output translation this
way is the problem here, but assigning memory resources to ambiguous
addresses is. The host bridge probe uses the 'ranges' both for
setting up the outbound window and the bus resources. 

If the PCI bus scan assigns address 0x8000_0000 to the memory BAR
of a device, and that device or any other one in the /same/
domain tries to DMA to DRAM at address 0x8000_0000, it would likely
reach the memory BAR instead of DRAM. If for some reason it does reach
DRAM after all, it would be unable to do a P2P DMA into the BAR when
it tries.

If the PCI scan already checks for overlap between the DT "ranges"
and other resources (DRAM or MMIO) before assigning a BAR, this may
be a non-issue, but I haven't found the code that does this.
Looking at pci_bus_allocate_dev_resources() it seems that it would
attempt to assign an overlapping address to a BAR but then fail
to claim it because of the resource conflict. If that is the
case, it would not actually have an ambiguous DMA routing
but instead the device would fail to be probed because of the
conflict.

    Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ