From: Jan Beulich <jbeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org,
Ross Lagerwall <ross.lagerwall@citrix.com>,
YueHaibing <yuehaibing@huawei.com>,
Simon Gaiser <simon@invisiblethingslab.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] xen-pciback: optionally allow interrupt enable flag writes
Date: Wed, 11 Dec 2019 16:49:29 +0100 [thread overview]
Message-ID: <17bf38dc-a606-bb92-50a8-9bd8f269acc2@suse.com> (raw)
In-Reply-To: <20191203054222.7966-1-marmarek@invisiblethingslab.com>
On 03.12.2019 06:41, Marek Marczykowski-Górecki wrote:
> QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> MSI(-X) enable flags in the PCI config space. This adds an attribute
> 'allow_interrupt_control' which when set for a PCI device allows writes
> to this flag(s). The toolstack will need to set this for stubdoms.
> When enabled, guest (stubdomain) will be allowed to set relevant enable
> flags, but only one at a time - i.e. it refuses to enable more than one
> of INTx, MSI, MSI-X at a time.
>
> This functionality is needed only for config space access done by device
> model (stubdomain) serving a HVM with the actual PCI device. It is not
> necessary and unsafe to enable direct access to those bits for PV domain
> with the device attached. For PV domains, there are separate protocol
> messages (XEN_PCI_OP_{enable,disable}_{msi,msix}) for this purpose.
> Those ops in addition to setting enable bits, also configure MSI(-X) in
> dom0 kernel - which is undesirable for PCI passthrough to HVM guests.
>
> This should not introduce any new security issues since a malicious
> guest (or stubdom) can already generate MSIs through other ways, see
> [1] page 8.
True, albeit this doesn't cover INTX_DISABLE.
> Additionally, when qemu runs in dom0, it already have direct
> access to those bits.
True again, but any bug here (as in: too wide exposure) is a qemu
bug (possibly security issue). The statement also isn't really
correct for de-privileged qemu, I think (but I also think PCI
pass-through doesn't work in that mode at all yet).
On the whole this looks to be an acceptable approach to me. But
I'm not the maintainer, so my opinion may not count much. Some
issues with the implementation itself were already pointed out.
Jan
prev parent reply other threads:[~2019-12-11 15:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 5:41 Marek Marczykowski-Górecki
2019-12-03 10:40 ` Jan Beulich
2019-12-03 15:17 ` [Xen-devel] " Roger Pau Monné
2019-12-19 3:51 ` Marek Marczykowski-Górecki
2019-12-11 15:49 ` Jan Beulich [this message]
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=17bf38dc-a606-bb92-50a8-9bd8f269acc2@suse.com \
--to=jbeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=ross.lagerwall@citrix.com \
--cc=simon@invisiblethingslab.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yuehaibing@huawei.com \
/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
Powered by JetHome