public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Radev <martin.b.radev@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: konrad.wilk@oracle.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: Mon, 18 Jan 2021 12:44:58 +0100	[thread overview]
Message-ID: <YAV0uhfkimXn1izW@martin> (raw)
In-Reply-To: <20210113113017.GA28106@lst.de>

On Wed, Jan 13, 2021 at 12:30:17PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 12, 2021 at 04:07:29PM +0100, Martin Radev wrote:
> > The size of the buffer being bounced is not checked if it happens
> > to be larger than the size of the mapped buffer. Because the size
> > can be controlled by a device, as it's the case with virtio devices,
> > this can lead to memory corruption.
> > 
> 
> I'm really worried about all these hodge podge hacks for not trusted
> hypervisors in the I/O stack.  Instead of trying to harden protocols
> that are fundamentally not designed for this, how about instead coming
> up with a new paravirtualized I/O interface that is specifically
> designed for use with an untrusted hypervisor from the start?

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.

Another possibility is to move this hardening to the common virtio code,
but I think the code may become more complicated there since it would
require tracking both the dma_addr and length for each descriptor.

  reply	other threads:[~2021-01-18 14:05 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 [this message]
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
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=YAV0uhfkimXn1izW@martin \
    --to=martin.b.radev@gmail.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=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.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