From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Wei Liu" <wl@xen.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
"Tim Deegan" <tim@xen.org>, "Julien Grall" <julien.grall@arm.com>,
xen-devel@lists.xenproject.org,
"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control
Date: Mon, 23 Sep 2019 14:25:49 +0200 [thread overview]
Message-ID: <20190923122549.GA15942@mail-itl> (raw)
In-Reply-To: <81326ccd-c27d-d97c-2a20-b39c1f42f5f0@suse.com>
[-- Attachment #1.1: Type: text/plain, Size: 1918 bytes --]
On Mon, Sep 23, 2019 at 02:05:58PM +0200, Jan Beulich wrote:
> On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> >> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> >>> Anyway, if you all agree that pciback should be the way to go, I can go
> >>> that route too. In practice, it would be a flag (set by the toolstack?)
> >>> allowing writes to appropriate config space registers directly (with
> >>> appropriate checks, as in this patch).
> >>
> >> I'm afraid I don't agree: How would allowing writes to more config space
> >> registers by a stubdom be safe?
> >
> > Exactly the same as in this patch: pciback would perform the same
> > validation (prohibit enabling MSI together with INTx etc).
> >
> > BTW what are the risks (besides DoS) of allowing full config space
> > access, assuming VT-d with interrupt remapping present? This sounds
> > similar to risks of malicious device connected to some domU, right? Can
> > such device (or a domain controlling such device) break out to Xen or
> > dom0? Can it steal data from other domains?
>
> There shouldn't be, but this would need proving. The direction of
> proof then should be the other way around (and I realize it may be
> [close to] impossible): Widening what guests (including stub
> domains) are allowed to do should be proven to add no additional
> risks. It shouldn't be (by example, as I imply from your question)
> that an actual issue needs to be pointed out.
What about this: HVM guest can already do all of this when qemu is
running in dom0. So, allowing those actions when qemu is running in
stubdomain should not introduce _additional_ risks.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-09-23 12:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 15:37 [Xen-devel] [PATCH v6 0/6] Fix PCI passthrough for HVM with stubdomain Marek Marczykowski-Górecki
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 1/6] libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use Marek Marczykowski-Górecki
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 2/6] libxl: attach PCI device to qemu only after setting pciback/pcifront Marek Marczykowski-Górecki
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 3/6] libxl: don't try to manipulate json config for stubdomain Marek Marczykowski-Górecki
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 4/6] xen/x86: Allow stubdom access to irq created for msi Marek Marczykowski-Górecki
2019-09-20 9:23 ` Jan Beulich
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control Marek Marczykowski-Górecki
2019-09-20 10:10 ` Jan Beulich
2019-09-20 16:02 ` Marek Marczykowski-Górecki
2019-09-23 7:58 ` Jan Beulich
2019-09-23 10:47 ` Marek Marczykowski-Górecki
2019-09-23 12:05 ` Jan Beulich
2019-09-23 12:25 ` Marek Marczykowski-Górecki [this message]
2019-09-23 13:02 ` Jan Beulich
2019-09-23 13:24 ` Marek Marczykowski-Górecki
2019-09-23 15:16 ` Roger Pau Monné
2019-09-14 15:37 ` [Xen-devel] [PATCH v6 6/6] tools/libxc: add wrapper for PHYSDEVOP_interrupt_control Marek Marczykowski-Górecki
2019-09-16 10:54 ` Wei Liu
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=20190923122549.GA15942@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=julien.grall@arm.com \
--cc=konrad.wilk@oracle.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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.