linux-kernel - Re: [PATCH v10 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654

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] [day] [month] [year] [list]

Message-ID: <0f52bdd7-0318-4762-8557-1fd1ab7a9f1f@wanadoo.fr>
Date: Tue, 22 Jul 2025 20:01:18 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: huaqian.li@...mens.com
Cc: baocheng.su@...mens.com, bhelgaas@...gle.com, conor+dt@...nel.org,
 devicetree@...r.kernel.org, diogo.ivo@...mens.com, helgaas@...nel.org,
 jan.kiszka@...mens.com, kristo@...nel.org, krzk+dt@...nel.org, kw@...ux.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-pci@...r.kernel.org, lpieralisi@...nel.org, nm@...com,
 robh@...nel.org, s-vadapalli@...com, ssantosh@...nel.org, vigneshr@...com
Subject: Re: [PATCH v10 4/7] PCI: keystone: Add support for PVU-based DMA
 isolation on AM654

Le 21/07/2025 à 04:59, 
huaqian.li-kv7WeFo6aLtBDgjK7y7TUQ@...lic.gmane.org a écrit :
> From: Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@...lic.gmane.org>
> 
> The AM654 lacks an IOMMU, thus does not support isolating DMA requests
> from untrusted PCI devices to selected memory regions this way. Use
> static PVU-based protection instead. The PVU, when enabled, will only
> accept DMA requests that address previously configured regions.
> 
> Use the availability of a restricted-dma-pool memory region as trigger
> and register it as valid DMA target with the PVU. In addition, enable
> the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
> VirtID so far, catching all devices.

Hi,

...

>   	case DW_PCIE_EP_TYPE:
>   		if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_EP)) {
> @@ -1346,6 +1450,8 @@ static int ks_pcie_probe(struct platform_device *pdev)
>   
>   err_ep_init:
>   	dw_pcie_ep_deinit(&pci->ep);
> +err_dma_cleanup:
> +	ks_release_restricted_dma(pdev);
>   err_get_sync:
>   	pm_runtime_put(dev);
>   	pm_runtime_disable(dev);
> @@ -1362,9 +1468,15 @@ static void ks_pcie_remove(struct platform_device *pdev)
>   {
>   	struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
>   	struct device_link **link = ks_pcie->link;
> +	const struct ks_pcie_of_data *data;
>   	int num_lanes = ks_pcie->num_lanes;
>   	struct device *dev = &pdev->dev;
>   
> +	data = of_device_get_match_data(dev);
> +	if (data && data->mode == DW_PCIE_RC_TYPE) {

If this test against DW_PCIE_RC_TYPE is needed in the remove function,
should the same be done in the error handling path of the probe?

If we go through "case DW_PCIE_EP_TYPE", we can end to "goto 
err_ep_init" and call ks_release_restricted_dma() unconditionally.

If it is not an issue in the error handling path of the probe, then I 
suppose that it can be removed from the remove function as well.


(and BTW, the extra {} could be removed)

CJ

> +		ks_release_restricted_dma(pdev);
> +	}
> +
>   	pm_runtime_put(dev);
>   	pm_runtime_disable(dev);
>   	ks_pcie_disable_phy(ks_pcie);