From patchwork Wed Jul 31 22:41:10 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony Krowiak X-Patchwork-Id: 11069733 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 72BE5746 for ; Wed, 31 Jul 2019 22:41:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 616A8204FA for ; Wed, 31 Jul 2019 22:41:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 54CD628068; Wed, 31 Jul 2019 22:41:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9A7E8204FA for ; Wed, 31 Jul 2019 22:41:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729758AbfGaWll (ORCPT ); Wed, 31 Jul 2019 18:41:41 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44128 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729652AbfGaWlj (ORCPT ); Wed, 31 Jul 2019 18:41:39 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6VMfdiS076980 for ; Wed, 31 Jul 2019 18:41:39 -0400 Received: from e14.ny.us.ibm.com (e14.ny.us.ibm.com [129.33.205.204]) by mx0a-001b2d01.pphosted.com with ESMTP id 2u3j3n4357-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jul 2019 18:41:38 -0400 Received: from localhost by e14.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 31 Jul 2019 23:41:28 +0100 Received: from b01cxnp22036.gho.pok.ibm.com (9.57.198.26) by e14.ny.us.ibm.com (146.89.104.201) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 31 Jul 2019 23:41:24 +0100 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6VMfLnS15139606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 Jul 2019 22:41:21 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9E27B28060; Wed, 31 Jul 2019 22:41:21 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7D7B2805A; Wed, 31 Jul 2019 22:41:20 +0000 (GMT) Received: from akrowiak-ThinkPad-P50.ibm.com (unknown [9.85.130.145]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTPS; Wed, 31 Jul 2019 22:41:20 +0000 (GMT) From: Tony Krowiak To: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: freude@linux.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.com, frankja@linux.ibm.com, david@redhat.com, mjrosato@linux.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, pmorel@linux.ibm.com, pasic@linux.ibm.com, alex.williamson@redhat.com, kwankhede@nvidia.com, Tony Krowiak Subject: [PATCH v5 0/7] s390: vfio-ap: dynamic configuration support Date: Wed, 31 Jul 2019 18:41:10 -0400 X-Mailer: git-send-email 2.7.4 X-TM-AS-GCONF: 00 x-cbid: 19073122-0052-0000-0000-000003E713B9 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011531; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000287; SDB=6.01240262; UDB=6.00654007; IPR=6.01021683; MB=3.00027986; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-31 22:41:26 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19073122-0053-0000-0000-000061EB0034 Message-Id: <1564612877-7598-1-git-send-email-akrowiak@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-31_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907310226 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. 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. 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. 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. 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. 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. * 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. 3. Rationale for hot plug/unplug using matrix mdev sysfs interfaces: ---------------------------------------------------------------- Allowing a user to hot plug/unplug AP resources using the matrix mdev sysfs interfaces circumvents the need to terminate the guest in order to modify its AP configuration. Allowing dynamic configuration makes reconfiguring a guest's AP matrix much less disruptive. 4. Rationale for allowing over-provisioning of AP resources: ----------------------------------------------------------- Allowing assignment of AP resources to a matrix mdev and ultimately to a guest better models the AP architecture. The architecture does not preclude assignment of unavailable AP resources. If a queue subsequently becomes available while a guest using the matrix mdev to which its APQN is assigned, the guest will automatically acquire access to it. If an APQN is dynamically unassigned from the underlying host system, it will automatically become unavailable to the guest. Change log v4-v5: ---------------- * Added a patch to provide kernel s390dbf debug logs for VFIO AP Change log v3->v4: ----------------- * Restored patches preventing root user from changing ownership of APQNs from zcrypt drivers to the vfio_ap driver if the APQN is assigned to an mdev. * No longer enforcing requirement restricting guest access to queues represented by a queue device bound to the vfio_ap device driver. * Removed shadow CRYCB and now directly updating the guest CRYCB from the matrix mdev's matrix. * Rebased the patch series on top of 'vfio: ap: AP Queue Interrupt Control' patches. * Disabled bind/unbind sysfs interfaces for vfio_ap driver Change log v2->v3: ----------------- * Allow guest access to an AP queue only if the queue is bound to the vfio_ap device driver. * Removed the patch to test CRYCB masks before taking the vCPUs out of SIE. Now checking the shadow CRYCB in the vfio_ap driver. Change log v1->v2: ----------------- * Removed patches preventing root user from unbinding AP queues from the vfio_ap device driver * Introduced a shadow CRYCB in the vfio_ap driver to manage dynamic changes to the AP guest configuration due to root user interventions or hardware anomalies. Tony Krowiak (7): s390: vfio-ap: Refactor vfio_ap driver 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: 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: add logging to vfio_ap driver s390: vfio-ap: update documentation Documentation/s390/vfio-ap.rst | 871 +++++++++++++++++++++++++--------- drivers/s390/crypto/ap_bus.c | 137 +++++- drivers/s390/crypto/ap_bus.h | 3 + drivers/s390/crypto/vfio_ap_drv.c | 87 +++- drivers/s390/crypto/vfio_ap_ops.c | 533 ++++++++++++--------- drivers/s390/crypto/vfio_ap_private.h | 26 +- 6 files changed, 1171 insertions(+), 486 deletions(-)