linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Srivatsa Vaddagiri <vatsa@codeaurora.org>,
	tsoni@codeaurora.org, virtio-dev@lists.oasis-open.org,
	konrad.wilk@oracle.com, jan.kiszka@siemens.com,
	jasowang@redhat.com, christoffer.dall@arm.com,
	virtualization@lists.linux-foundation.org,
	alex.bennee@linaro.org, iommu@lists.linux-foundation.org,
	stefano.stabellini@xilinx.com, will@kernel.org,
	linux-kernel@vger.kernel.org, pratikp@codeaurora.org
Subject: Re: [PATCH 5/5] virtio: Add bounce DMA ops
Date: Wed, 29 Apr 2020 00:57:43 -0400	[thread overview]
Message-ID: <20200429004531-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <275eba4b-dd35-aa95-b2e3-9c5cbf7c6d71@linux.intel.com>

On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote:
> On 2020/4/29 4:41, Michael S. Tsirkin wrote:
> > On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote:
> > > * Michael S. Tsirkin<mst@redhat.com>  [2020-04-28 12:17:57]:
> > > 
> > > > Okay, but how is all this virtio specific?  For example, why not allow
> > > > separate swiotlbs for any type of device?
> > > > For example, this might make sense if a given device is from a
> > > > different, less trusted vendor.
> > > Is swiotlb commonly used for multiple devices that may be on different trust
> > > boundaries (and not behind a hardware iommu)?
> > Even a hardware iommu does not imply a 100% security from malicious
> > hardware. First lots of people use iommu=pt for performance reasons.
> > Second even without pt, unmaps are often batched, and sub-page buffers
> > might be used for DMA, so we are not 100% protected at all times.
> > 
> 
> For untrusted devices, IOMMU is forced on even iommu=pt is used;

I think you are talking about untrusted *drivers* like with VFIO.

On the other hand, I am talking about things like thunderbolt
peripherals being less trusted than on-board ones.

Or possibly even using swiotlb for specific use-cases where
speed is less of an issue.

E.g. my wifi is pretty slow anyway, and that card is exposed to
malicious actors all the time, put just that behind swiotlb
for security, and leave my graphics card with pt since
I'm trusting it with secrets anyway.


> and
> iotlb flush is in strict mode (no batched flushes); ATS is also not
> allowed. Swiotlb is used to protect sub-page buffers since IOMMU can
> only apply page granularity protection. Swiotlb is now used for devices
> from different trust zone.
> 
> Best regards,
> baolu


  reply	other threads:[~2020-04-29  4:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 11:39 [PATCH 0/5] virtio on Type-1 hypervisor Srivatsa Vaddagiri
2020-04-28 11:39 ` [PATCH 1/5] swiotlb: Introduce concept of swiotlb_pool Srivatsa Vaddagiri
2020-04-29  0:31   ` kbuild test robot
2020-04-28 11:39 ` [PATCH 2/5] swiotlb: Allow for non-linear mapping between paddr and vaddr Srivatsa Vaddagiri
2020-04-28 11:39 ` [PATCH 3/5] swiotlb: Add alloc and free APIs Srivatsa Vaddagiri
2020-04-30  4:18   ` kbuild test robot
2020-04-28 11:39 ` [PATCH 4/5] swiotlb: Add API to register new pool Srivatsa Vaddagiri
2020-04-28 11:39 ` [PATCH 5/5] virtio: Add bounce DMA ops Srivatsa Vaddagiri
2020-04-28 16:17   ` Michael S. Tsirkin
2020-04-28 17:49     ` Srivatsa Vaddagiri
2020-04-28 20:41       ` Michael S. Tsirkin
2020-04-28 23:04         ` Stefano Stabellini
2020-04-29  4:09           ` Srivatsa Vaddagiri
2020-04-29  2:22         ` Lu Baolu
2020-04-29  4:57           ` Michael S. Tsirkin [this message]
2020-04-29  5:42             ` Lu Baolu
2020-04-29  6:50               ` Michael S. Tsirkin
2020-04-29  7:01                 ` Lu Baolu
2020-04-29  9:44                 ` Srivatsa Vaddagiri
2020-04-29  9:52                   ` Michael S. Tsirkin
2020-04-29 10:09                     ` Srivatsa Vaddagiri
2020-04-29 10:20                       ` Michael S. Tsirkin
2020-04-29 10:26                         ` Jan Kiszka
2020-04-29 10:45                           ` Michael S. Tsirkin
2020-04-29 10:55                             ` [virtio-dev] " Jan Kiszka
2020-04-29 10:34                         ` Srivatsa Vaddagiri
2020-04-30 15:20                         ` Konrad Rzeszutek Wilk
2020-04-29  3:35         ` Srivatsa Vaddagiri
2020-04-28 21:35   ` kbuild test robot
2020-04-28 22:18   ` kbuild test robot
2020-04-28 22:53   ` Stefano Stabellini
2020-04-29 21:06   ` kbuild test robot
2020-04-29 21:06   ` [RFC PATCH] virtio: virtio_pool can be static kbuild test robot

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=20200429004531-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=christoffer.dall@arm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jan.kiszka@siemens.com \
    --cc=jasowang@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pratikp@codeaurora.org \
    --cc=stefano.stabellini@xilinx.com \
    --cc=tsoni@codeaurora.org \
    --cc=vatsa@codeaurora.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will@kernel.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).