iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>, Claire Chang <tientzu@chromium.org>
Cc: heikki.krogerus@linux.intel.com, peterz@infradead.org,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	grant.likely@arm.com, paulus@samba.org, will@kernel.org,
	mingo@kernel.org, sstabellini@kernel.org, saravanak@google.com,
	mpe@ellerman.id.au, rafael.j.wysocki@intel.com, hch@lst.de,
	bgolaszewski@baylibre.com, xen-devel@lists.xenproject.org,
	treding@nvidia.com, devicetree@vger.kernel.org,
	konrad.wilk@oracle.com, dan.j.williams@intel.com,
	drinkcat@chromium.org, boris.ostrovsky@oracle.com,
	andriy.shevchenko@linux.intel.com, jgross@suse.com,
	gregkh@linuxfoundation.org, rdunlap@infradead.org,
	frowand.list@gmail.com, iommu@lists.linux-foundation.org,
	xypron.glpk@gmx.de, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
Date: Wed, 20 Jan 2021 17:30:07 +0000	[thread overview]
Message-ID: <313f8052-a591-75de-c4c2-ee9ea8f02e7f@arm.com> (raw)
In-Reply-To: <20210120165348.GA220770@robh.at.kernel.org>

On 2021-01-20 16:53, Rob Herring wrote:
> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
>> Introduce the new compatible string, restricted-dma-pool, for restricted
>> DMA. One can specify the address and length of the restricted DMA memory
>> region by restricted-dma-pool in the device tree.
> 
> If this goes into DT, I think we should be able to use dma-ranges for
> this purpose instead. Normally, 'dma-ranges' is for physical bus
> restrictions, but there's no reason it can't be used for policy or to
> express restrictions the firmware has enabled.

There would still need to be some way to tell SWIOTLB to pick up the 
corresponding chunk of memory and to prevent the kernel from using it 
for anything else, though.

>> Signed-off-by: Claire Chang <tientzu@chromium.org>
>> ---
>>   .../reserved-memory/reserved-memory.txt       | 24 +++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> index e8d3096d922c..44975e2a1fd2 100644
>> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
>>             used as a shared pool of DMA buffers for a set of devices. It can
>>             be used by an operating system to instantiate the necessary pool
>>             management subsystem if necessary.
>> +        - restricted-dma-pool: This indicates a region of memory meant to be
>> +          used as a pool of restricted DMA buffers for a set of devices. The
>> +          memory region would be the only region accessible to those devices.
>> +          When using this, the no-map and reusable properties must not be set,
>> +          so the operating system can create a virtual mapping that will be used
>> +          for synchronization. The main purpose for restricted DMA is to
>> +          mitigate the lack of DMA access control on systems without an IOMMU,
>> +          which could result in the DMA accessing the system memory at
>> +          unexpected times and/or unexpected addresses, possibly leading to data
>> +          leakage or corruption. The feature on its own provides a basic level
>> +          of protection against the DMA overwriting buffer contents at
>> +          unexpected times. However, to protect against general data leakage and
>> +          system memory corruption, the system needs to provide way to restrict
>> +          the DMA to a predefined memory region.
>>           - vendor specific string in the form <vendor>,[<device>-]<usage>
>>   no-map (optional) - empty property
>>       - Indicates the operating system must not create a virtual mapping
>> @@ -120,6 +134,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
>>   			compatible = "acme,multimedia-memory";
>>   			reg = <0x77000000 0x4000000>;
>>   		};
>> +
>> +		restricted_dma_mem_reserved: restricted_dma_mem_reserved {
>> +			compatible = "restricted-dma-pool";
>> +			reg = <0x50000000 0x400000>;
>> +		};
>>   	};
>>   
>>   	/* ... */
>> @@ -138,4 +157,9 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
>>   		memory-region = <&multimedia_reserved>;
>>   		/* ... */
>>   	};
>> +
>> +	pcie_device: pcie_device@0,0 {
>> +		memory-region = <&restricted_dma_mem_reserved>;
> 
> PCI hosts often have inbound window configurations that limit the
> address range and translate PCI to bus addresses. Those windows happen
> to be configured by dma-ranges. In any case, wouldn't you want to put
> the configuration in the PCI host node? Is there a usecase of
> restricting one PCIe device and not another?

The general design seems to accommodate devices having their own pools 
such that they can't even snoop on each others' transient DMA data. If 
the interconnect had a way of wiring up, say, PCI RIDs to AMBA NSAIDs, 
then in principle you could certainly apply that to PCI endpoints too 
(presumably you'd also disallow them from peer-to-peer transactions at 
the PCI level too).

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-01-20 17:30 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  3:41 [RFC PATCH v3 0/6] Restricted DMA Claire Chang
2021-01-06  3:41 ` [RFC PATCH v3 1/6] swiotlb: Add io_tlb_mem struct Claire Chang
2021-01-13 11:50   ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool Claire Chang
2021-01-06  7:50   ` Greg KH
2021-01-13 11:51     ` Christoph Hellwig
2021-01-13 12:29       ` Greg KH
2021-01-13 12:37         ` Christoph Hellwig
2021-01-06 18:52   ` Konrad Rzeszutek Wilk
2021-01-07 17:39     ` Claire Chang
2021-01-07 17:57       ` Konrad Rzeszutek Wilk
2021-01-07 18:09         ` Florian Fainelli
2021-01-07 21:19           ` Konrad Rzeszutek Wilk
2021-01-12 23:52             ` Florian Fainelli
2021-01-25  5:26           ` Jon Masters
2021-01-13  1:53         ` Robin Murphy
2021-01-13  0:03   ` Florian Fainelli
2021-01-13 13:59     ` Nicolas Saenz Julienne
2021-01-13 15:27       ` Robin Murphy
2021-01-13 17:43         ` Florian Fainelli
2021-01-13 18:03           ` Robin Murphy
2021-01-13 12:42   ` Christoph Hellwig
2021-01-14  9:06     ` Claire Chang
2021-01-06  3:41 ` [RFC PATCH v3 3/6] swiotlb: Use restricted DMA pool if available Claire Chang
2021-01-12 23:39   ` Florian Fainelli
2021-01-13 12:44   ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-01-12 23:41   ` Florian Fainelli
2021-01-13 12:48   ` Christoph Hellwig
2021-01-13 18:27     ` Robin Murphy
2021-01-13 18:32       ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-01-06 18:57   ` Konrad Rzeszutek Wilk
2021-01-07 17:39     ` Claire Chang
2021-01-07 18:00       ` Konrad Rzeszutek Wilk
2021-01-07 18:14         ` Florian Fainelli
2021-01-12  7:47           ` Claire Chang
2021-01-20 16:53   ` Rob Herring
2021-01-20 17:30     ` Robin Murphy [this message]
2021-01-20 21:31       ` Rob Herring
2021-01-21  1:09         ` Robin Murphy
2021-01-21 15:48           ` Rob Herring
2021-01-21 17:29             ` Robin Murphy
2021-01-06  3:41 ` [RFC PATCH v3 6/6] of: Add plumbing for " Claire Chang
2021-01-12 23:48   ` Florian Fainelli
2021-01-14  9:08     ` Claire Chang
2021-01-14 18:52       ` Florian Fainelli
2021-01-15  3:46         ` Claire Chang
2021-01-06 18:48 ` [RFC PATCH v3 0/6] Restricted DMA Florian Fainelli
2021-01-07 17:38   ` Claire Chang
2021-01-07 17:42   ` Claire Chang
2021-01-07 17:59     ` Florian Fainelli
2021-01-12  7:48       ` Claire Chang
2021-01-12 18:01         ` Florian Fainelli
2021-01-13  2:29           ` Tomasz Figa
2021-01-13  3:56             ` Florian Fainelli
2021-01-13  4:25               ` Tomasz Figa
2021-01-13  4:41                 ` Florian Fainelli
2021-02-09  6:27                   ` Claire Chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=313f8052-a591-75de-c4c2-ee9ea8f02e7f@arm.com \
    --to=robin.murphy@arm.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=sstabellini@kernel.org \
    --cc=tientzu@chromium.org \
    --cc=treding@nvidia.com \
    --cc=will@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).