From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Martin Radev <martin.b.radev@gmail.com>,
m.szyprowski@samsung.com, robin.murphy@arm.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
joro@8bytes.org, kirill.shutemov@linux.intel.com,
thomas.lendacky@amd.com, robert.buhren@sect.tu-berlin.de,
file@sect.tu-berlin.de, mathias.morbitzer@aisec.fraunhofer.de,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path
Date: Wed, 3 Feb 2021 14:36:38 -0500 [thread overview]
Message-ID: <20210203193638.GA325136@fedora> (raw)
In-Reply-To: <20210203124922.GB16923@lst.de>
On Wed, Feb 03, 2021 at 01:49:22PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> > Your comment makes sense but then that would require the cooperation
> > of these vendors and the cloud providers to agree on something meaningful.
> > I am also not sure whether the end result would be better than hardening
> > this interface to catch corruption. There is already some validation in
> > unmap path anyway.
>
> So what? If you guys want to provide a new capability you'll have to do
> work. And designing a new protocol based around the fact that the
> hardware/hypervisor is not trusted and a copy is always required makes
> a lot of more sense than throwing in band aids all over the place.
If you don't trust the hypervisor, what would this capability be in?
I suppose you mean this would need to be in the the guest kernel and
this protocol would depend on .. not-hypervisor and most certainly not
the virtio or any SR-IOV device. That removes a lot of options.
The one sensibile one (since folks will trust OEM vendors like Intel
or AMD to provide the memory encryption so they will also trust the
IOMMU - I hope?) - and they do have plans for that with their IOMMU
frameworks which will remove the need for SWIOTLB (I hope).
But that is not now, but in future.
next prev parent reply other threads:[~2021-02-03 19:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <X/27MSbfDGCY9WZu@martin>
2021-01-13 11:30 ` [PATCH] swiotlb: Validate bounce size in the sync/unmap path Christoph Hellwig
2021-01-18 11:44 ` Martin Radev
2021-01-18 15:14 ` Konrad Rzeszutek Wilk
2021-01-25 18:33 ` Martin Radev
2021-02-02 16:37 ` Konrad Rzeszutek Wilk
2021-02-02 22:34 ` Tom Lendacky
2021-02-02 23:13 ` Konrad Rzeszutek Wilk
2021-02-03 12:49 ` Christoph Hellwig
2021-02-03 19:36 ` Konrad Rzeszutek Wilk [this message]
2021-02-05 17:58 ` Christoph Hellwig
2021-02-08 17:14 ` Konrad Rzeszutek Wilk
2021-02-09 8:26 ` 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=20210203193638.GA325136@fedora \
--to=konrad.wilk@oracle.com \
--cc=file@sect.tu-berlin.de \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin.b.radev@gmail.com \
--cc=mathias.morbitzer@aisec.fraunhofer.de \
--cc=robert.buhren@sect.tu-berlin.de \
--cc=robin.murphy@arm.com \
--cc=thomas.lendacky@amd.com \
--cc=virtualization@lists.linux-foundation.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).