From: Pierre Morel <pmorel@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>, Tony Krowiak <akrowiak@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, freude@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, alex.williamson@redhat.com,
kwankhede@nvidia.com, jjherne@linux.ibm.com
Subject: Re: [PATCH v6 00/10] s390: vfio-ap: dynamic configuration support
Date: Tue, 8 Oct 2019 14:57:07 +0200 [thread overview]
Message-ID: <ddd4e91a-312d-99e4-1f54-7bf3b03fb63e@linux.ibm.com> (raw)
In-Reply-To: <20191008124807.49022238.pasic@linux.ibm.com>
On 10/8/19 12:48 PM, Halil Pasic wrote:
> On Fri, 13 Sep 2019 17:26:48 -0400
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>> The current design for AP pass-through does not support making dynamic
>> changes to the AP matrix of a running guest resulting in three deficiencies
>> this patch series is intended to mitigate:
>>
>> 1. Adapters, domains and control domains can not be added to or removed
>> from a running guest. In order to modify a guest's AP configuration,
>> the guest must be terminated; only then can AP resources be assigned
>> to or unassigned from the guest's matrix mdev. The new AP configuration
>> becomes available to the guest when it is subsequently restarted.
>>
>> 2. The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask interfaces can
>> be modified by a root user without any restrictions. A change to either
>> mask can result in AP queue devices being unbound from the vfio_ap
>> device driver and bound to a zcrypt device driver even if a guest is
>> using the queues, thus giving the host access to the guest's private
>> crypto data and vice versa.
>>
>> 3. The APQNs derived from the Cartesian product of the APIDs of the
>> adapters and APQIs of the domains assigned to a matrix mdev must
>> reference an AP queue device bound to the vfio_ap device driver.
>>
>> This patch series introduces the following changes to the current design
>> to alleviate the shortcomings described above as well as to implement more
>> of the AP architecture:
>>
>> 1. A root user will be prevented from making changes to the AP bus's
>> /sys/bus/ap/apmask or /sys/bus/ap/aqmask if the ownership of an APQN
>> changes from the vfio_ap device driver to a zcrypt driver when the APQN
>> is assigned to a matrix mdev.
>>
>> 2. The sysfs bind/unbind interfaces will be disabled for the vfio_ap
>> device driver.
>>
> Doesn't this have the potential of breaking some userspace stuff that
> might be out there?
>
>> 3. Allow AP resources to be assigned to or removed from a matrix mdev
>> while a guest is using it and hot plug the resource into or hot unplug
>> the resource from the running guest.
> This looks like a natural extension of the interface -- i.e. should not
> break any userspace.
>
>> 4. Allow assignment of an AP adapter or domain to a matrix mdev even if it
>> results in assignment of an APQN that does not reference an AP queue
>> device bound to the vfio_ap device driver, as long as the APQN is owned
>> by the vfio_ap driver. Allowing over-provisioning of AP resources
>> better models the architecture which does not preclude assigning AP
>> resources that are not yet available in the system. If/when the queue
>> becomes available to the host, it will immediately also become available
>> to the guest.
> Same here -- I don't think this change breaks any userspace.
>
>> 1. Rationale for changes to AP bus's apmask/aqmask interfaces:
>> ----------------------------------------------------------
>> Due to the extremely sensitive nature of cryptographic data, it is
>> imperative that great care be taken to ensure that such data is secured.
>> Allowing a root user, either inadvertently or maliciously, to configure
>> these masks such that a queue is shared between the host and a guest is
>> not only avoidable, it is advisable.
Just curious: how is it possible to do such a configuration?
>> It was suggested that this scenario
>> is better handled in user space with management software, but that does
>> not preclude a malicious administrator from using the sysfs interfaces
>> to gain access to a guest's crypto data. It was also suggested that this
>> scenario could be avoided by taking access to the adapter away from the
>> guest and zeroing out the queues prior to the vfio_ap driver releasing the
>> device; however, stealing an adapter in use from a guest as a by-product
>> of an operation is bad and will likely cause problems for the guest
>> unnecessarily. It was decided that the most effective solution with the
>> least number of negative side effects is to prevent the situation at the
>> source.
Stealing an adapter in use by a guest, insn't it what is done if we
allow to unassign an AP/Domain using the unassign sysfs interface when
the mediated device is in use by the guest?
>>
>> 2. Rationale for disabling bind/unbind interfaces for vfio_ap driver:
>> -----------------------------------------------------------------
>> By disabling the bind/unbind interfaces for the vfio_ap device driver,
>> the user is forced to use the AP bus's apmask/aqmask interfaces to control
>> the probing and removing of AP queues. There are two primary reasons for
>> disabling the bind/unbind interfaces for the vfio_ap device driver:
>>
>> * The device architecture does not provide a means to prevent unbinding
>> a device from a device driver, so an AP queue device can be unbound
>> from the vfio_ap driver even when the queue is in use by a guest. By
>> disabling the unbind interface, the user is forced to use the AP bus's
>> apmask/aqmask interfaces which will prevent this.
>>
> Isn't this fixed by your filtering (if implemented correctly)? BTW I believe
> it solves the problem regardless whether the unbind was triggered by the
> drivers unbind attribute or by a[pq]mask
>
>> * Binding of AP queues is controlled by the AP bus /sys/bus/ap/apmask and
>> /sys/bus/ap/aqmask interfaces. If the masks indicate that an APQN is
>> owned by zcrypt, trying to bind it to the vfio_ap device driver will
>> fail; therefore, the bind interface is somewhat redundant and certainly
>> unnecessary.
>>
>>
>>
>> Tony Krowiak (10):
>> s390: vfio-ap: Refactor vfio_ap driver probe and remove callbacks
>> s390: vfio-ap: allow assignment of unavailable AP resources to mdev
>> device
>> s390: vfio-ap: allow hot plug/unplug of AP resources using mdev device
>> s390: vfio-ap: filter CRYCB bits for unavailable queue devices
>> s390: vfio-ap: sysfs attribute to display the guest CRYCB
>> s390: vfio-ap: update guest CRYCB in vfio_ap probe and remove
>> callbacks
>> s390: zcrypt: driver callback to indicate resource in use
>> s390: vfio-ap: implement in-use callback for vfio_ap driver
>> s390: vfio-ap: added versioning to vfio_ap module
>> s390: vfio-ap: update documentation
> I believe it would be worthwhile to reorder the patches (fixes and
> re-factoring first, the features).
>
> Regards,
> Halil
>
>> Documentation/s390/vfio-ap.rst | 899 +++++++++++++++++++++++++---------
>> drivers/s390/crypto/ap_bus.c | 144 +++++-
>> drivers/s390/crypto/ap_bus.h | 4 +
>> drivers/s390/crypto/vfio_ap_drv.c | 27 +-
>> drivers/s390/crypto/vfio_ap_ops.c | 610 ++++++++++++++---------
>> drivers/s390/crypto/vfio_ap_private.h | 12 +-
>> 6 files changed, 1200 insertions(+), 496 deletions(-)
>>
--
Pierre Morel
IBM Lab Boeblingen
next prev parent reply other threads:[~2019-10-08 12:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 21:26 [PATCH v6 00/10] s390: vfio-ap: dynamic configuration support Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 01/10] s390: vfio-ap: Refactor vfio_ap driver probe and remove callbacks Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 02/10] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 03/10] s390: vfio-ap: allow hot plug/unplug of AP resources using " Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 04/10] s390: vfio-ap: filter CRYCB bits for unavailable queue devices Tony Krowiak
2019-09-18 17:04 ` Halil Pasic
2019-09-18 21:22 ` Tony Krowiak
2019-09-19 10:34 ` Halil Pasic
2019-09-20 14:24 ` Tony Krowiak
2019-09-20 15:44 ` Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 05/10] s390: vfio-ap: sysfs attribute to display the guest CRYCB Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 06/10] s390: vfio-ap: update guest CRYCB in vfio_ap probe and remove callbacks Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 07/10] s390: zcrypt: driver callback to indicate resource in use Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 08/10] s390: vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 09/10] s390: vfio-ap: added versioning to vfio_ap module Tony Krowiak
2019-09-13 21:26 ` [PATCH v6 10/10] s390: vfio-ap: update documentation Tony Krowiak
2019-10-08 10:48 ` [PATCH v6 00/10] s390: vfio-ap: dynamic configuration support Halil Pasic
2019-10-08 12:57 ` Pierre Morel [this message]
2019-10-15 20:33 ` Tony Krowiak
2019-10-15 20:27 ` Tony Krowiak
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=ddd4e91a-312d-99e4-1f54-7bf3b03fb63e@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=freude@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).