From: Jason Gunthorpe <jgg@nvidia.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>,
Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Jiang, Dave" <dave.jiang@intel.com>,
"wangzhou1@hisilicon.com" <wangzhou1@hisilicon.com>,
"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
"vkoul@kernel.org" <vkoul@kernel.org>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags
Date: Thu, 13 May 2021 16:00:40 -0300 [thread overview]
Message-ID: <20210513190040.GR1002214@nvidia.com> (raw)
In-Reply-To: <20210513185349.GA801495@agluck-desk2.amr.corp.intel.com>
On Thu, May 13, 2021 at 11:53:49AM -0700, Luck, Tony wrote:
> I'd like people to think of DSA as an extension to the instruction
> set. It implements asynchronous instructions like "MEMFILL" and
> "MEMCOPY". These can be limited in scope when executed in user
> processes or guests. But when executed by the host OS ring0 code
> they can have all the same access that ring0 code has when it
> dereferences a pointer.
If you want this then be explicit about what it is you are making when
building the API. Don't try to hide it under some generic idea of
"kernel PCI DMA SVA"
Add appropriately safe APIs that might have a chance of making it
secure, eg by confirming it is a physically trusted on-socket device.
It is not just Thunderbolt devices that could trigger this, many
devices with programmable firmware can spoof PCI DID/VID - having an
exploit chain that compromises a in-system FW device, chains it to
faking a IDXD HW, then accessing the all-memory PASID is pretty
alarming if the admin thought they had protection against DMA attacks.
I could easially see an admin option to "turn this off" entirely as
being too dangerous, especially if the users have no interest in IDXD.
Which is why being explicit of intent is really important.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "vkoul@kernel.org" <vkoul@kernel.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Jiang, Dave" <dave.jiang@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
David Woodhouse <dwmw2@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
Jean-Philippe Brucker <jean-philippe@linaro.com>
Subject: Re: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags
Date: Thu, 13 May 2021 16:00:40 -0300 [thread overview]
Message-ID: <20210513190040.GR1002214@nvidia.com> (raw)
In-Reply-To: <20210513185349.GA801495@agluck-desk2.amr.corp.intel.com>
On Thu, May 13, 2021 at 11:53:49AM -0700, Luck, Tony wrote:
> I'd like people to think of DSA as an extension to the instruction
> set. It implements asynchronous instructions like "MEMFILL" and
> "MEMCOPY". These can be limited in scope when executed in user
> processes or guests. But when executed by the host OS ring0 code
> they can have all the same access that ring0 code has when it
> dereferences a pointer.
If you want this then be explicit about what it is you are making when
building the API. Don't try to hide it under some generic idea of
"kernel PCI DMA SVA"
Add appropriately safe APIs that might have a chance of making it
secure, eg by confirming it is a physically trusted on-socket device.
It is not just Thunderbolt devices that could trigger this, many
devices with programmable firmware can spoof PCI DID/VID - having an
exploit chain that compromises a in-system FW device, chains it to
faking a IDXD HW, then accessing the all-memory PASID is pretty
alarming if the admin thought they had protection against DMA attacks.
I could easially see an admin option to "turn this off" entirely as
being too dangerous, especially if the users have no interest in IDXD.
Which is why being explicit of intent is really important.
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-05-13 19:00 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 13:25 [PATCH v4 0/2] Simplify and restrict IOMMU SVA APIs Jacob Pan
2021-05-10 13:25 ` Jacob Pan
2021-05-10 13:25 ` [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags Jacob Pan
2021-05-10 13:25 ` Jacob Pan
2021-05-10 23:37 ` Jason Gunthorpe
2021-05-10 23:37 ` Jason Gunthorpe
2021-05-11 3:31 ` Jacob Pan
2021-05-11 3:31 ` Jacob Pan
2021-05-11 11:48 ` Jason Gunthorpe
2021-05-11 11:48 ` Jason Gunthorpe
2021-05-11 16:14 ` Jacob Pan
2021-05-11 16:14 ` Jacob Pan
2021-05-11 16:35 ` Jason Gunthorpe
2021-05-11 16:35 ` Jason Gunthorpe
2021-05-11 18:05 ` Jacob Pan
2021-05-11 18:05 ` Jacob Pan
2021-05-11 19:47 ` Jason Gunthorpe
2021-05-11 19:47 ` Jason Gunthorpe
2021-05-12 6:37 ` Christoph Hellwig
2021-05-12 6:37 ` Christoph Hellwig
2021-05-13 13:00 ` Jacob Pan
2021-05-13 13:00 ` Jacob Pan
2021-05-13 13:38 ` Jason Gunthorpe
2021-05-13 13:38 ` Jason Gunthorpe
2021-05-13 15:10 ` Jacob Pan
2021-05-13 15:10 ` Jacob Pan
2021-05-13 16:44 ` Luck, Tony
2021-05-13 16:44 ` Luck, Tony
2021-05-13 17:33 ` Jason Gunthorpe
2021-05-13 17:33 ` Jason Gunthorpe
2021-05-13 18:53 ` Luck, Tony
2021-05-13 18:53 ` Luck, Tony
2021-05-13 19:00 ` Jason Gunthorpe [this message]
2021-05-13 19:00 ` Jason Gunthorpe
2021-05-13 19:14 ` Luck, Tony
2021-05-13 19:14 ` Luck, Tony
2021-05-13 19:20 ` Jason Gunthorpe
2021-05-13 19:20 ` Jason Gunthorpe
2021-05-13 19:46 ` Jacob Pan
2021-05-13 19:46 ` Jacob Pan
2021-05-13 19:57 ` Luck, Tony
2021-05-13 19:57 ` Luck, Tony
2021-05-13 20:22 ` Jacob Pan
2021-05-13 20:22 ` Jacob Pan
2021-05-13 22:31 ` Jason Gunthorpe
2021-05-13 22:31 ` Jason Gunthorpe
2021-05-13 23:40 ` Jacob Pan
2021-05-13 23:40 ` Jacob Pan
2021-05-17 14:37 ` Jason Gunthorpe
2021-05-17 14:37 ` Jason Gunthorpe
2021-05-19 15:46 ` Jacob Pan
2021-05-19 15:46 ` Jacob Pan
2021-05-12 10:18 ` Jean-Philippe Brucker
2021-05-12 10:18 ` Jean-Philippe Brucker
2021-05-10 13:25 ` [PATCH v4 2/2] iommu/sva: Remove mm parameter from SVA bind API Jacob Pan
2021-05-10 13:25 ` Jacob Pan
2021-05-12 10:24 ` Jean-Philippe Brucker
2021-05-12 10:24 ` Jean-Philippe Brucker
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=20210513190040.GR1002214@nvidia.com \
--to=jgg@nvidia.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=vkoul@kernel.org \
--cc=wangzhou1@hisilicon.com \
--cc=yi.l.liu@intel.com \
--cc=zhangfei.gao@linaro.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 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.