Re: [PATCH 0/6] drm+dma: cache support for arm, etc

From: "Koenig, Christian" <Christian.Koenig@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>,
	Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Eric Biggers <ebiggers@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Will Deacon <will@kernel.org>,
	Emil Velikov <emil.velikov@collabora.com>,
	Rob Clark <robdclark@chromium.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Burton <paul.burton@mips.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
	<linux-arm-kernel@lists.infradead.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	open list:DRM DRIVER FOR MSM ADRENO GPU
Subject: Re: [PATCH 0/6] drm+dma: cache support for arm, etc
Date: Thu, 15 Aug 2019 18:48:39 +0000	[thread overview]
Message-ID: <215e5cb7-0fcf-48db-a656-817054dde420@email.android.com> (raw)

[-- Attachment #1.1: Type: text/plain, Size: 1314 bytes --]

Sorry if the style is messed up, replying from my phone.

Am 15.08.2019 20:27 schrieb Christoph Hellwig <hch@lst.de>:
On Thu, Aug 15, 2019 at 06:21:00PM +0000, Koenig, Christian wrote:
> >   (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
> >       of dma_alloc_attrs.  The initial difference with that flag is just
> >       that we allow highmem, but in the future we could also unmap this
> >       memory from the kernel linear mapping entirely on architectures
> >       where we can easily do that.
>
> Mhm, why would we want to do this?

To avoid the CPU misspeculating into this memory.  For example NVMe SSDs
have a feature called host memory buffer that is a lot like your stolen
main ram for the GPU case.  We currently hand the SSD a
DMA_ATTR_NO_KERNEL_MAPPING allocation if it requests such a buffer.  If
possible we'd really like to make sure no speculative execution bug
(or intentional attacker with a kernel exploit for that matter) can easily
access that memory.

Well, for the graphics case I absolutely need to keep the linear kernel mapping. Because for certain use cases the memory is accessed by the kernel all the time as well.

Why should accessing uncached memory be more of a security problem than accessing cached?

Regards,
Christian

[-- Attachment #1.2: Type: text/html, Size: 2507 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel