All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	YueHaibing <yuehaibing@huawei.com>,
	open list <linux-kernel@vger.kernel.org>,
	Simon Gaiser <simon@invisiblethingslab.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4] xen-pciback: optionally allow interrupt enable flag writes
Date: Wed, 15 Jan 2020 17:32:32 -0500	[thread overview]
Message-ID: <393ff73f-802c-9f1c-b739-4476388b6c98@oracle.com> (raw)
In-Reply-To: <20200115164815.GO11756@Air-de-Roger>



On 1/15/20 11:48 AM, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 02:46:29AM +0100, 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. Additionally, when qemu runs in dom0, it already have direct
>> access to those bits.
>>
>> This is the second iteration of this feature. First was proposed as a
>> direct Xen interface through a new hypercall, but ultimately it was
>> rejected by the maintainer, because of mixing pciback and hypercalls for
>> PCI config space access isn't a good design. Full discussion at [2].
>>
>> [1]: https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
>> [2]: https://xen.markmail.org/thread/smpgpws4umdzizze
>>
>> [part of the commit message and sysfs handling]
>> Signed-off-by: Simon Gaiser <simon@invisiblethingslab.com>
>> [the rest]
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Some minor nits below, but LGTM:
>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-pciback b/Documentation/ABI/testing/sysfs-driver-pciback
>> index 6a733bfa37e6..566a11f2c12f 100644
>> --- a/Documentation/ABI/testing/sysfs-driver-pciback
>> +++ b/Documentation/ABI/testing/sysfs-driver-pciback
>> @@ -11,3 +11,16 @@ Description:
>>                   #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
>>                   will allow the guest to read and write to the configuration
>>                   register 0x0E.
>> +
>> +What:           /sys/bus/pci/drivers/pciback/allow_interrupt_control
>> +Date:           Jan 2020
>> +KernelVersion:  5.5

5.6

I can fix this and the things that Roger mentioned while committing if 
Marek is OK with that.

-boris




WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	YueHaibing <yuehaibing@huawei.com>,
	open list <linux-kernel@vger.kernel.org>,
	Simon Gaiser <simon@invisiblethingslab.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4] xen-pciback: optionally allow interrupt enable flag writes
Date: Wed, 15 Jan 2020 17:32:32 -0500	[thread overview]
Message-ID: <393ff73f-802c-9f1c-b739-4476388b6c98@oracle.com> (raw)
In-Reply-To: <20200115164815.GO11756@Air-de-Roger>



On 1/15/20 11:48 AM, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 02:46:29AM +0100, 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. Additionally, when qemu runs in dom0, it already have direct
>> access to those bits.
>>
>> This is the second iteration of this feature. First was proposed as a
>> direct Xen interface through a new hypercall, but ultimately it was
>> rejected by the maintainer, because of mixing pciback and hypercalls for
>> PCI config space access isn't a good design. Full discussion at [2].
>>
>> [1]: https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
>> [2]: https://xen.markmail.org/thread/smpgpws4umdzizze
>>
>> [part of the commit message and sysfs handling]
>> Signed-off-by: Simon Gaiser <simon@invisiblethingslab.com>
>> [the rest]
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Some minor nits below, but LGTM:
>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-pciback b/Documentation/ABI/testing/sysfs-driver-pciback
>> index 6a733bfa37e6..566a11f2c12f 100644
>> --- a/Documentation/ABI/testing/sysfs-driver-pciback
>> +++ b/Documentation/ABI/testing/sysfs-driver-pciback
>> @@ -11,3 +11,16 @@ Description:
>>                   #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
>>                   will allow the guest to read and write to the configuration
>>                   register 0x0E.
>> +
>> +What:           /sys/bus/pci/drivers/pciback/allow_interrupt_control
>> +Date:           Jan 2020
>> +KernelVersion:  5.5

5.6

I can fix this and the things that Roger mentioned while committing if 
Marek is OK with that.

-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-15 22:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  1:46 [PATCH v4] xen-pciback: optionally allow interrupt enable flag writes Marek Marczykowski-Górecki
2020-01-15  1:46 ` [Xen-devel] " Marek Marczykowski-Górecki
2020-01-15 16:48 ` Roger Pau Monné
2020-01-15 16:48   ` Roger Pau Monné
2020-01-15 22:32   ` Boris Ostrovsky [this message]
2020-01-15 22:32     ` Boris Ostrovsky
2020-01-15 22:45     ` Marek Marczykowski-Górecki
2020-01-15 22:45       ` Marek Marczykowski-Górecki

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=393ff73f-802c-9f1c-b739-4476388b6c98@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=roger.pau@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 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.