From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jason Wang <jasowang@redhat.com>
Cc: ashish.kalra@amd.com, Felicitas Hetzelt <file@sect.tu-berlin.de>,
"Radev, Martin" <martin.radev@aisec.fraunhofer.de>,
david.kaplan@amd.com, "Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux-foundation.org,
Robert Buhren <robert@sect.tu-berlin.de>,
iommu@lists.linux-foundation.org, "Morbitzer,
Mathias" <mathias.morbitzer@aisec.fraunhofer.de>,
hch@lst.de
Subject: Re: swiotlb/virtio: unchecked device dma address and length
Date: Tue, 15 Dec 2020 09:27:55 -0500 [thread overview]
Message-ID: <20201215142755.GB28810@char.us.oracle.com> (raw)
In-Reply-To: <c3629a27-3590-1d9f-211b-c0b7be152b32@redhat.com>
.snip.
> > > This raises two issues:
> > > 1) swiotlb_tlb_unmap_single fails to check whether the index generated
> > > from the dma_addr is in range of the io_tlb_orig_addr array.
> > That is fairly simple to implement I would think. That is it can check
> > that the dma_addr is from the PA in the io_tlb pool when SWIOTLB=force
> > is used.
>
>
> I'm not sure this can fix all the cases. It looks to me we should map
> descriptor coherent but readonly (which is not supported by current DMA
> API).
I think I am missing something obvious here. The attacker is the hypervisor, aka
the owner of the VirtIO device (ring0). The attacker is the one that
provides the addr/len - having that readonly from a guest perspective
does not change the fact that the hypervisor can modify the memory range
by mapping it via a different virtual address in the hypervisor? (aka
aliasing it).
>
> Otherwise, device can modify the desc[i].addr/desc[i].len at any time to
> pretend a valid mapping.
With the swiotlb=force as long as addr/len are within the PA boundaries
within the SWIOTLB pool this should be OK?
After all that whole area is in cleartext and visible to the attacker.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-12-15 14:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 17:31 swiotlb/virtio: unchecked device dma address and length Felicitas Hetzelt
2020-12-14 21:49 ` Konrad Rzeszutek Wilk
2020-12-15 3:20 ` Jason Wang
2020-12-15 14:27 ` Konrad Rzeszutek Wilk [this message]
2020-12-16 5:53 ` Jason Wang
2020-12-16 6:41 ` Jason Wang
2020-12-16 13:04 ` Konrad Rzeszutek Wilk
2020-12-17 4:19 ` Jason Wang
2020-12-17 22:55 ` Ashish Kalra
2020-12-16 8:54 ` Michael S. Tsirkin
2020-12-16 13:07 ` Konrad Rzeszutek Wilk
2020-12-16 22:07 ` Radev, Martin
2020-12-17 23:17 ` Ashish Kalra
2020-12-18 9:28 ` Radev, Martin
2020-12-15 8:47 ` Ashish Kalra
2020-12-15 10:54 ` Felicitas Hetzelt
2020-12-15 14:37 ` Konrad Rzeszutek Wilk
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=20201215142755.GB28810@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=ashish.kalra@amd.com \
--cc=david.kaplan@amd.com \
--cc=file@sect.tu-berlin.de \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=martin.radev@aisec.fraunhofer.de \
--cc=mathias.morbitzer@aisec.fraunhofer.de \
--cc=mst@redhat.com \
--cc=robert@sect.tu-berlin.de \
--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).