From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Hillf Danton <hdanton@sina.com>, Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
Matthew Wilcox <willy@infradead.org>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf
Date: Mon, 7 Sep 2020 09:49:08 +0200 [thread overview]
Message-ID: <20200907074908.GA20762@lst.de> (raw)
In-Reply-To: <1eb4a2b0-2fd4-9f3c-e610-c8f856027181@samsung.com>
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.
prev parent reply other threads:[~2020-09-07 7:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200904152550.17964-1-hdanton@sina.com>
2020-09-04 15:34 ` [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf James Bottomley
[not found] ` <20200905073528.9464-1-hdanton@sina.com>
2020-09-05 15:46 ` James Bottomley
2020-09-05 15:50 ` James Bottomley
2020-09-07 7:02 ` Marek Szyprowski
2020-09-07 7:49 ` Christoph Hellwig [this message]
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=20200907074908.GA20762@lst.de \
--to=hch@lst.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hdanton@sina.com \
--cc=keescook@chromium.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=willy@infradead.org \
/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).