On 6/27/19 3:25 AM, Cornelia Huck wrote:
On Wed, 26 Jun 2019 17:13:50 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
On 6/19/19 9:04 AM, Tony Krowiak wrote:
On 6/18/19 12:25 PM, Cornelia Huck wrote:
On Thu, 13 Jun 2019 15:39:36 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
Introduces a new driver callback to prevent a root user from unbinding
an AP queue from its device driver if the queue is in use. This prevents
a root user from inadvertently taking a queue away from a guest and
giving it to the host, or vice versa. The callback will be invoked
whenever a change to the AP bus's apmask or aqmask sysfs interfaces may
result in one or more AP queues being removed from its driver. If the
callback responds in the affirmative for any driver queried, the change
to the apmask or aqmask will be rejected with a device in use error.
For this patch, only non-default drivers will be queried. Currently,
there is only one non-default driver, the vfio_ap device driver. The
vfio_ap device driver manages AP queues passed through to one or more
guests and we don't want to unexpectedly take AP resources away from
guests which are most likely independently administered.
Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
---
drivers/s390/crypto/ap_bus.c | 138
+++++++++++++++++++++++++++++++++++++++++--
drivers/s390/crypto/ap_bus.h | 3 +
2 files changed, 135 insertions(+), 6 deletions(-)
Hm... I recall objecting to this patch before, fearing that it makes it
possible for a bad actor to hog resources that can't be removed by
root, even forcefully. (I have not had time to look at the intervening
versions, so I might be missing something.)
Is there a way for root to forcefully override this?
You recall correctly; however, after many internal crypto team
discussions, it was decided that this feature was important
and should be kept.
Allow me to first address your fear that a bad actor can hog
resources that can't be removed by root. With this enhancement,
there is nothing preventing a root user from taking resources
from a matrix mdev, it simply forces him/her to follow the
proper procedure. The resources to be removed must first be
unassigned from the matrix mdev to which they are assigned.
The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask
sysfs attributes can then be edited to transfer ownership
of the resources to zcrypt.
The rationale for keeping this feature is:
* It is a bad idea to steal an adapter in use from a guest. In the worst
case, the guest could end up without access to any crypto adapters
without knowing why. This could lead to performance issues on guests
that rely heavily on crypto such as guests used for blockchain
transactions.
* There are plenty of examples in linux of the kernel preventing a root
user from performing a task. For example, a module can't be removed
if references are still held for it. Another example would be trying
to bind a CEX4 adapter to a device driver not registered for CEX4;
this action will also be rejected.
* The semantics are much cleaner and the logic is far less complicated.
* It forces the use of the proper procedure to change ownership of AP
queues.
Any feedback on this?
Had not yet time to look at this, sorry.
No problem, just wanted to make sure it didn't get lost in the shuffle.
Tony K
