linux-kernel - Re: [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Mar 2022 18:43:03 -0500
From:   Tony Krowiak <akrowiak@...ux.ibm.com>
To:     jjherne@...ux.ibm.com, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     freude@...ux.ibm.com, borntraeger@...ibm.com, cohuck@...hat.com,
        mjrosato@...ux.ibm.com, pasic@...ux.ibm.com,
        alex.williamson@...hat.com, kwankhede@...dia.com,
        fiuczy@...ux.ibm.com
Subject: Re: [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering
 APQNs assigned to mdev



On 3/2/22 14:35, Jason J. Herne wrote:
> On 2/14/22 19:50, Tony Krowiak wrote:
>> Refresh the guest's APCB by filtering the APQNs assigned to the 
>> matrix mdev
>> that do not reference an AP queue device bound to the vfio_ap device
>> driver. The mdev's APQNs will be filtered according to the following 
>> rules:
>>
>> * The APID of each adapter and the APQI of each domain that is not in 
>> the
>> host's AP configuration is filtered out.
>>
>> * The APID of each adapter comprising an APQN that does not reference a
>> queue device bound to the vfio_ap device driver is filtered. The APQNs
>> are derived from the Cartesian product of the APID of each adapter and
>> APQI of each domain assigned to the mdev.
>>
>> The control domains that are not assigned to the host's AP configuration
>> will also be filtered before assigning them to the guest's APCB.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@...ux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 96 ++++++++++++++++++++++++++++++-
>>   1 file changed, 93 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
>> b/drivers/s390/crypto/vfio_ap_ops.c
>> index 4b676a55f203..b67b2f0faeea 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -317,6 +317,63 @@ static void vfio_ap_matrix_init(struct 
>> ap_config_info *info,
>>       matrix->adm_max = info->apxa ? info->Nd : 15;
>>   }
>>   +static void vfio_ap_mdev_filter_cdoms(struct ap_matrix_mdev 
>> *matrix_mdev)
>> +{
>> +    bitmap_and(matrix_mdev->shadow_apcb.adm, matrix_mdev->matrix.adm,
>> +           (unsigned long *)matrix_dev->info.adm, AP_DOMAINS);
>> +}
>> +
>> +/*
>> + * vfio_ap_mdev_filter_matrix - copy the mdev's AP configuration to 
>> the KVM
>> + *                guest's APCB then filter the APIDs that do not
>> + *                comprise at least one APQN that references a
>> + *                queue device bound to the vfio_ap device driver.
>> + *
>> + * @matrix_mdev: the mdev whose AP configuration is to be filtered.
>> + */
>> +static void vfio_ap_mdev_filter_matrix(unsigned long *apm, unsigned 
>> long *aqm,
>> +                       struct ap_matrix_mdev *matrix_mdev)
>> +{
>> +    int ret;
>> +    unsigned long apid, apqi, apqn;
>> +
>> +    ret = ap_qci(&matrix_dev->info);
>> +    if (ret)
>> +        return;
>> +
>> +    vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
>
> Do you need to call vfio_ap_matrix_init here? It seems to me like this 
> would
> only be necesarry if apxa could be dynamically added or removed. Here 
> is a
> copy of vfio_ap_matrix_init, for reference:
>
> static void vfio_ap_matrix_init(struct ap_config_info *info,
>                 struct ap_matrix *matrix)
> {
>     matrix->apm_max = info->apxa ? info->Na : 63;
>     matrix->aqm_max = info->apxa ? info->Nd : 15;
>     matrix->adm_max = info->apxa ? info->Nd : 15;
> }
>
> It seems like this should be figured out once and stored when the
> ap_matrix_mdev struct is first created. Unless I'm wrong, and the 
> status of
> apxa can change dynamically, in which case the maximums would need to be
> updated somewhere.

It's an interesting question to which I don't have a definitive answer. 
I'll run it
by our architects. On the other hand, making this call here is not entirely
unreasonable and merely superfluous at worst, but I'll look into it.

Tony K

>
>