linux-kernel - Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

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: <7ed51025f051f65f3dfe10a88caeb648821994b1.camel@suse.de>
Date:   Wed, 13 Jan 2021 14:59:34 +0100
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Claire Chang <tientzu@...omium.org>, robh+dt@...nel.org,
        mpe@...erman.id.au, benh@...nel.crashing.org, paulus@...ba.org,
        joro@...tes.org, will@...nel.org, frowand.list@...il.com,
        konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
        jgross@...e.com, sstabellini@...nel.org, hch@....de,
        m.szyprowski@...sung.com, robin.murphy@....com
Cc:     drinkcat@...omium.org, devicetree@...r.kernel.org,
        heikki.krogerus@...ux.intel.com, saravanak@...gle.com,
        peterz@...radead.org, xypron.glpk@....de,
        rafael.j.wysocki@...el.com, linux-kernel@...r.kernel.org,
        andriy.shevchenko@...ux.intel.com, bgolaszewski@...libre.com,
        iommu@...ts.linux-foundation.org, grant.likely@....com,
        rdunlap@...radead.org, gregkh@...uxfoundation.org,
        xen-devel@...ts.xenproject.org, dan.j.williams@...el.com,
        treding@...dia.com, linuxppc-dev@...ts.ozlabs.org, mingo@...nel.org
Subject: Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

Hi All,

On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
> On 1/5/21 7:41 PM, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes in the device tree.
> > 
> > Signed-off-by: Claire Chang <tientzu@...omium.org>
> > ---
> >  include/linux/device.h  |   4 ++
> >  include/linux/swiotlb.h |   7 +-
> >  kernel/dma/Kconfig      |   1 +
> >  kernel/dma/swiotlb.c    | 144 ++++++++++++++++++++++++++++++++++------
> >  4 files changed, 131 insertions(+), 25 deletions(-)
> > 
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 89bb8b84173e..ca6f71ec8871 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -413,6 +413,7 @@ struct dev_links_info {
> >   * @dma_pools:	Dma pools (if dma'ble device).
> >   * @dma_mem:	Internal for coherent mem override.
> >   * @cma_area:	Contiguous memory area for dma allocations
> > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> >   * @archdata:	For arch-specific additions.
> >   * @of_node:	Associated device tree node.
> >   * @fwnode:	Associated device node supplied by platform firmware.
> > @@ -515,6 +516,9 @@ struct device {
> >  #ifdef CONFIG_DMA_CMA
> >  	struct cma *cma_area;		/* contiguous memory area for dma
> >  					   allocations */
> > +#endif
> > +#ifdef CONFIG_SWIOTLB
> > +	struct io_tlb_mem	*dma_io_tlb_mem;
> >  #endif
> >  	/* arch specific additions */
> >  	struct dev_archdata	archdata;
> > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> > index dd8eb57cbb8f..a1bbd7788885 100644
> > --- a/include/linux/swiotlb.h
> > +++ b/include/linux/swiotlb.h
> > @@ -76,12 +76,13 @@ extern enum swiotlb_force swiotlb_force;
> >   *
> >   * @start:	The start address of the swiotlb memory pool. Used to do a quick
> >   *		range check to see if the memory was in fact allocated by this
> > - *		API.
> > + *		API. For restricted DMA pool, this is device tree adjustable.
> 
> Maybe write it as this is "firmware adjustable" such that when/if ACPI
> needs something like this, the description does not need updating.
> 
> [snip]
> 
> > +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> > +				    struct device *dev)
> > +{
> > +	struct io_tlb_mem *mem = rmem->priv;
> > +	int ret;
> > +
> > +	if (dev->dma_io_tlb_mem)
> > +		return -EBUSY;
> > +
> > +	if (!mem) {
> > +		mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> > +		if (!mem)
> > +			return -ENOMEM;
> > +
> > +		if (!memremap(rmem->base, rmem->size, MEMREMAP_WB)) {
> 
> MEMREMAP_WB sounds appropriate as a default.

As per the binding 'no-map' has to be disabled here. So AFAIU, this memory will
be part of the linear mapping. Is this really needed then?

> Documentation/devicetree/bindings/reserved-memory/ramoops.txt does
> define an "unbuffered" property which in premise could be applied to the
> generic reserved memory binding as well and that we may have to be
> honoring here, if we were to make it more generic. Oh well, this does
> not need to be addressed right now I guess.




Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)