[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200907074908.GA20762@lst.de>
Date: Mon, 7 Sep 2020 09:49:08 +0200
From: Christoph Hellwig <hch@....de>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
Hillf Danton <hdanton@...a.com>,
Christoph Hellwig <hch@....de>, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
Matthew Wilcox <willy@...radead.org>,
linux-arch@...r.kernel.org
Subject: Re: [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf
On Mon, Sep 07, 2020 at 09:02:34AM +0200, Marek Szyprowski wrote:
> > That's not a reason ... that comment was put in for coherent mappings.
> > What is the reason we should incur all this expense for clearing pages
> > which aren't unmapped in the kernel, because we can update the comment?
> > The usual rationale for kernel mapped pages is security, because they
> > may leak information but unmapped pages shouldn't have this problem.
>
> Any dma_alloc_attrs() buffer might be mmaped to userspace, so the
> security reason is still valid. Possible lack if kernel mapping was only
> a hint that driver doesn't need it, so it might be skipped on some
> architectures, where creating it requires significant resources (i.e.
> vmalloc area).
Yes. It seems actually mapping it to userspace in media/drm drivers
seems to be one of the big use cases. There other one is memory not
used by the host at all and just as an extra buffer for hardware so
that the PCIe device can cut down on DRAM cost. For that could
potentially skip the zeroing, but then again you'd need to trust the
device, which with thunderbolt might not always be a good idea.
Powered by blists - more mailing lists