lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 16 Dec 2020 15:14:47 -0500
From:   Tony Krowiak <>
To:     Halil Pasic <>
Subject: Re: [PATCH v12 11/17] s390/vfio-ap: allow assignment of unavailable
 AP queues to mdev device

On 11/28/20 8:17 PM, Halil Pasic wrote:
> On Tue, 24 Nov 2020 16:40:10 -0500
> Tony Krowiak <> wrote:
>> The current implementation does not allow assignment of an AP adapter or
>> domain to an mdev device if each APQN resulting from the assignment
>> does not reference an AP queue device that is bound to the vfio_ap device
>> driver. This patch allows assignment of AP resources to the matrix mdev as
>> long as the APQNs resulting from the assignment:
>>     1. Are not reserved by the AP BUS for use by the zcrypt device drivers.
>>     2. Are not assigned to another matrix mdev.
>> The rationale behind this is twofold:
>>     1. The AP architecture does not preclude assignment of APQNs to an AP
>>        configuration that are not available to the system.
>>     2. APQNs that do not reference a queue device bound to the vfio_ap
>>        device driver will not be assigned to the guest's CRYCB, so the
>>        guest will not get access to queues not bound to the vfio_ap driver.
>> Signed-off-by: Tony Krowiak <>
> Again code looks good. I'm still worried about all the incremental
> changes (good for review) and their testability.

I'm not sure what your concern is here. Is there an expectation
that each patch needs to be testable by itself, or whether the
functionality in each patch can be easily tested en masse?

I'm not sure some of these changes can be tested with an
automated test because the test code would have to be able to
dynamically change the host's AP configuration and I don't know
if there is currently a way to do this programmatically. In order to
test the effects of dynamic host crypto configuration manually, one
needs access to an SE or HMC with DPM.

Powered by blists - more mailing lists