linux-kernel - RE: [PATCH] genirq/msi: Check null pointer before copying struct msi

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: <CY4PR12MB1271277CEE4F1FE06B71DDE8DAD60@CY4PR12MB1271.namprd12.prod.outlook.com>
Date:   Sat, 18 Apr 2020 15:19:41 +0000
From:   Gustavo Pimentel <Gustavo.Pimentel@...opsys.com>
To:     Marc Zyngier <maz@...nel.org>, Alan Mikhak <alan.mikhak@...ive.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kishon@...com" <kishon@...com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>
Subject: RE: [PATCH] genirq/msi: Check null pointer before copying struct
 msi_msg

Hi Marc and Alan,

> I'm not convinced by this. If you know that, by construction, these
> interrupts are not associated with an underlying MSI, why calling
> get_cached_msi_msg() the first place?
> 
> There seem to be some assumptions in the DW EDMA driver that the
> signaling would be MSI based, so maybe someone from Synopsys (Gustavo?)
> could clarify that. From my own perspective, running on an endpoint
> device means that it is *generating* interrupts, and I'm not sure what
> the MSIs represent here.

Giving a little context to this topic.

The eDMA IP present on the Synopsys DesignWare PCIe Endpoints can be 
configured and triggered *remotely* as well *locally*.
For the sake of simplicity let's assume for now the eDMA was implemented 
on the EP and that is the IP that we want to configure and use.

When I say *remotely* I mean that this IP can be configurable through the 
RC/CPU side, however, for that, it requires the eDMA registers to be 
exposed through a PCIe BAR on the EP. This will allow setting the SAR, 
DAR and other settings, also need(s) the interrupt(s) address(es) to be 
set as well (MSI or MSI-X only) so that it can signal through PCIe (to 
the RC and consecutively the associated EP driver) if the data transfer 
has been completed, aborted or if the Linked List consumer algorithm has 
passed in some linked element marked with a watermark.

It was based on this case that the eDMA driver was exclusively developed.

However, Alan, wants to expand a little more this, by being able to use 
this driver on the EP side (through 
pcitest/pci_endpoint_test/pci_epf_test) so that he can configure this IP 
*locally*.
In fact, when doing this, he doesn't need to configure the interrupt 
address (MSI or MSI-X), because this IP provides a local interrupt line 
so that be connected to other blocks on the EP side.

Regards,
Gustavo