From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: eric.auger@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH] virtio-iommu: Default to bypass during boot
Date: Thu, 25 Feb 2021 18:13:24 +0100 [thread overview]
Message-ID: <YDfatCDUZ3FISPJI@myrica> (raw)
In-Reply-To: <20210221064211-mutt-send-email-mst@kernel.org>
On Sun, Feb 21, 2021 at 06:45:18AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 18, 2021 at 11:59:30AM +0100, Jean-Philippe Brucker wrote:
> > Currently the virtio-iommu device must be programmed before it allows
> > DMA from any PCI device. This can make the VM entirely unusable when a
> > virtio-iommu driver isn't present, for example in a bootloader that
> > loads the OS from storage.
> >
> > Similarly to the other vIOMMU implementations, default to DMA bypassing
> > the IOMMU during boot. Add a "boot-bypass" option that lets users change
> > this behavior.
> >
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>
> wouldn't this be a spec violation?
>
>
> When the device is reset, endpoints are not attached to any domain.
>
> If the VIRTIO_IOMMU_F_BYPASS feature is negotiated, all accesses from
> unattached endpoints are allowed and translated by the IOMMU using the
> identity function. If the feature is not negotiated, any memory access
> from an unattached endpoint fails. Upon attaching an endpoint in
> bypass mode to a new domain, any memory access from the endpoint fails,
> since the domain does not contain any mapping.
Right, but the device behavior regarding BYPASS is specified as:
If the driver does not accept the VIRTIO_IOMMU_F_BYPASS feature, the
device SHOULD NOT let endpoints access the guest-physical address space.
So I figured that the spec could be read as "before feature negotiation
it's undefined whether the IOMMU is bypassed or not" and so a device
implementation can choose either (previously discussed at [1]). But it's a
stretch, we should clarify this.
Also, the OS might want to know whether DMA was bypassing the IOMMU before
the device is initialized. If there are strong security requirements, then
boot-bypass means the system was vulnerable to DMA attacks during boot.
So I'd like to add a new feature bit for this, VIRTIO_IOMMU_F_BOOT_BYPASS,
that tells whether DMA bypasses the IOMMU before feature negotiation. It's
only an indicator, accepting the feature doesn't change anything. I'll
send the spec change shortly.
Thanks,
Jean
[1] https://lore.kernel.org/qemu-devel/20200109104032.GA937123@myrica/
> Maybe it's not too late to change the spec here - want to try sending
> a spec patch?
next prev parent reply other threads:[~2021-02-25 17:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 10:59 [PATCH] virtio-iommu: Default to bypass during boot Jean-Philippe Brucker
2021-02-21 11:45 ` Michael S. Tsirkin
2021-02-25 17:13 ` Jean-Philippe Brucker [this message]
2021-02-26 8:11 ` Tian, Kevin
2021-02-26 13:00 ` Jean-Philippe Brucker
2021-03-04 7:59 ` Tian, Kevin
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=YDfatCDUZ3FISPJI@myrica \
--to=jean-philippe@linaro.org \
--cc=eric.auger@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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.