All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
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>,
	Imre Deak <imre.deak@intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Emil Velikov <emil.velikov@collabora.com>,
	Rob Clark <robdclark@chromium.org>,
	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>,
	Linus Walleij <linus.walleij@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU"
	<linux-arm-msm@vger.kernel.org>,
	"Sharma, Deepak" <Deepak.Sharma@amd.com>,
	Joerg Roedel <jroedel@suse.de>, Arnd Bergmann <arnd@arndb.de>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	"Wolfram Sang \(Renesas\)" <wsa+renesas@sang-engineering.com>,
	"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
	<linuxppc-dev@lists.ozlabs.org>,
	Alexios Zavras <alexios.zavras@intel.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Doug Anderson <armlinux@m.disordat.com>,
	Thomas Gleixner <tglx@linutronix.de>, Sean Paul <sean@poorly.run>,
	Allison Randal <allison@lohutok.net>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Enrico Weigelt <info@metux.net>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Clark <robdclark@gmail.com>,
	Souptick Joarder <jrdr.linux@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU"
	<freedreno@lists.freedesktop.org>
Subject: Re: [PATCH 0/6] drm+dma: cache support for arm, etc
Date: Thu, 15 Aug 2019 20:27:42 +0200	[thread overview]
Message-ID: <20190815182742.GA20859@lst.de> (raw)
In-Reply-To: <e3f73b3c-49d5-3c19-dfff-0a24b4617e50@amd.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
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>,
	Imre Deak <imre.deak@intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	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>,
	Linus Walleij <linus.walleij@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU"
	<linux-arm-msm@vger.kernel.org>,
	"Sharma, Deepak" <Deepak.Sharma@amd.com>,
	Joerg Roedel <jroedel@suse.de>, Arnd Bergmann <arnd@arndb.de>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	"Wolfram Sang \(Renesas\)" <wsa+renesas@sang-engineering.com>,
	"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
	<linuxppc-dev@lists.ozlabs.org>,
	Alexios Zavras <alexios.zavras@intel.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Doug Anderson <armlinux@m.disordat.com>,
	Thomas Gleixner <tglx@linutronix.de>, Sean Paul <sean@poorly.run>,
	Allison Randal <allison@lohutok.net>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Enrico Weigelt <info@metux.net>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Clark <robdclark@gmail.com>,
	Souptick Joarder <jrdr.linux@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU"
	<freedreno@lists.freedesktop.org>
Subject: Re: [PATCH 0/6] drm+dma: cache support for arm, etc
Date: Thu, 15 Aug 2019 20:27:42 +0200	[thread overview]
Message-ID: <20190815182742.GA20859@lst.de> (raw)
In-Reply-To: <e3f73b3c-49d5-3c19-dfff-0a24b4617e50@amd.com>

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Cc: Kate Stewart
	<kstewart-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Masayoshi Mizuma
	<m.mizuma-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	"Maciej W. Rozycki"
	<macro-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	Eric Biggers <ebiggers-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Imre Deak <imre.deak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Chris Wilson
	<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>,
	Masahiro Yamada
	<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>,
	Benjamin Gaignard
	<benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mauro Carvalho Chehab
	<mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Will Deacon <will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Emil Velikov
	<emil.velikov-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>,
	Rob Clark <robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
	Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>,
	Mike Rapoport <rppt-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Daniel
Subject: Re: [PATCH 0/6] drm+dma: cache support for arm, etc
Date: Thu, 15 Aug 2019 20:27:42 +0200	[thread overview]
Message-ID: <20190815182742.GA20859@lst.de> (raw)
In-Reply-To: <e3f73b3c-49d5-3c19-dfff-0a24b4617e50-5C7GfCeVMHo@public.gmane.org>

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.
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

  reply	other threads:[~2019-08-15 18:29 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 21:59 [PATCH 0/6] drm+dma: cache support for arm, etc Rob Clark
2019-08-14 21:59 ` Rob Clark
2019-08-14 21:59 ` Rob Clark
2019-08-14 21:59 ` [PATCH 1/6] arm64: export arch_sync_dma_for_*() Rob Clark
2019-08-14 21:59   ` Rob Clark
2019-08-14 21:59 ` [PATCH 2/6] mips: " Rob Clark
2019-08-14 21:59   ` Rob Clark
2019-08-14 21:59 ` [PATCH 3/6] powerpc: " Rob Clark
2019-08-14 21:59   ` Rob Clark
2019-08-14 21:59 ` [PATCH 4/6] arm: add arch_sync_dma_for_*() Rob Clark
2019-08-14 21:59   ` Rob Clark
2019-08-14 21:59   ` Rob Clark
2019-08-14 22:00 ` [PATCH 5/6] drm/msm: stop abusing DMA API Rob Clark
2019-08-14 22:00 ` [PATCH 6/6] drm/vgem: fix cache synchronization on arm/arm64 (take two) Rob Clark
2019-08-15  6:51 ` [PATCH 0/6] drm+dma: cache support for arm, etc Christoph Hellwig
2019-08-15  6:51   ` Christoph Hellwig
2019-08-15  6:51   ` Christoph Hellwig
2019-08-15 13:54   ` Rob Clark
2019-08-15 13:54     ` Rob Clark
2019-08-15 13:54     ` Rob Clark
2019-08-15 17:53     ` Christoph Hellwig
2019-08-15 17:53       ` Christoph Hellwig
2019-08-15 17:53       ` Christoph Hellwig
2019-08-15 18:21       ` Koenig, Christian
2019-08-15 18:21         ` Koenig, Christian
2019-08-15 18:21         ` Koenig, Christian
2019-08-15 18:27         ` Christoph Hellwig [this message]
2019-08-15 18:27           ` Christoph Hellwig
2019-08-15 18:27           ` Christoph Hellwig
2019-08-16 21:04       ` Rob Clark
2019-08-16 21:04         ` Rob Clark
2019-08-16 21:04         ` Rob Clark
2019-08-19  5:23         ` Christoph Hellwig
2019-08-19  5:23           ` Christoph Hellwig
2019-08-19  5:23           ` Christoph Hellwig
2019-08-19 14:39           ` Rob Clark
2019-08-19 14:39             ` Rob Clark
2019-08-19 14:39             ` Rob Clark
  -- strict thread matches above, loose matches on Subject: below --
2019-08-15 18:48 Koenig, Christian
2019-08-15 18:48 ` Koenig, Christian
2019-08-15 18:52 ` Christoph Hellwig
2019-08-15 18:52   ` Christoph Hellwig
2019-08-15 18:52   ` Christoph Hellwig

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=20190815182742.GA20859@lst.de \
    --to=hch@lst.de \
    --cc=Christian.Koenig@amd.com \
    --cc=Deepak.Sharma@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexios.zavras@intel.com \
    --cc=allison@lohutok.net \
    --cc=anshuman.khandual@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=armlinux@m.disordat.com \
    --cc=arnd@arndb.de \
    --cc=benjamin.gaignard@linaro.org \
    --cc=brouer@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiggers@google.com \
    --cc=emil.velikov@collabora.com \
    --cc=freedreno@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hauke@hauke-m.de \
    --cc=imre.deak@intel.com \
    --cc=info@metux.net \
    --cc=jrdr.linux@gmail.com \
    --cc=jroedel@suse.de \
    --cc=kstewart@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.mizuma@jp.fujitsu.com \
    --cc=macro@linux-mips.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=paul.burton@mips.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=rppt@linux.ibm.com \
    --cc=sean@poorly.run \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=yamada.masahiro@socionext.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.