linux-kernel - Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix

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]

Message-Id: <edf541b4-f3d6-95ac-46c8-32560c1d0b0c@linux.ibm.com>
Date:   Wed, 16 May 2018 16:41:41 +0200
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     freude@...ibm.com, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, borntraeger@...ibm.com,
        cohuck@...hat.com, kwankhede@...dia.com,
        bjsdjshi@...ux.vnet.ibm.com, pbonzini@...hat.com,
        alex.williamson@...hat.com, pmorel@...ux.vnet.ibm.com,
        alifm@...ux.vnet.ibm.com, mjrosato@...ux.vnet.ibm.com,
        jjherne@...ux.vnet.ibm.com, thuth@...hat.com,
        pasic@...ux.vnet.ibm.com, berrange@...hat.com,
        fiuczy@...ux.vnet.ibm.com, buendgen@...ibm.com
Subject: Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP
 matrix

On 16/05/2018 16:29, Tony Krowiak wrote:
> On 05/11/2018 12:08 PM, Halil Pasic wrote:
>>
>>
>> On 05/07/2018 05:11 PM, Tony Krowiak wrote:
>>> Provides interfaces to manage the AP adapters, usage domains
>>> and control domains assigned to a KVM guest.
>>>
>>> The guest's SIE state description has a satellite structure called the
>>> Crypto Control Block (CRYCB) containing three bitmask fields
>>> identifying the adapters, queues (domains) and control domains
>>> assigned to the KVM guest:
>>
>> [..]
>>
>>> index 00bcfb0..98b53c7 100644
>>> --- a/arch/s390/kvm/kvm-ap.c
>>> +++ b/arch/s390/kvm/kvm-ap.c
>>> @@ -7,6 +7,7 @@
>>
>> [..]
>>
>>> +
>>> +/**
>>> + * kvm_ap_validate_queue_sharing
>>> + *
>>> + * Verifies that the APQNs derived from the cross product of the AP 
>>> adapter IDs
>>> + * and AP queue indexes comprising the AP matrix are not configured 
>>> for
>>> + * another guest. AP queue sharing is not allowed.
>>> + *
>>> + * @kvm: the KVM guest
>>> + * @matrix: the AP matrix
>>> + *
>>> + * Returns 0 if the APQNs are valid, otherwise; returns -EBUSY.
>>> + */
>>> +static int kvm_ap_validate_queue_sharing(struct kvm *kvm,
>>> +                     struct kvm_ap_matrix *matrix)
>>> +{
>>> +    struct kvm *vm;
>>> +    unsigned long *apm, *aqm;
>>> +    unsigned long apid, apqi;
>>> +
>>> +
>>> +    /* No other VM may share an AP Queue with the input VM */
>>> +    list_for_each_entry(vm, &vm_list, vm_list) {
>>> +        if (kvm == vm)
>>> +            continue;
>>> +
>>> +        apm = kvm_ap_get_crycb_apm(vm);
>>> +        if (!bitmap_and(apm, apm, matrix->apm, matrix->apm_max + 1))
>>> +            continue;
>>> +
>>> +        aqm = kvm_ap_get_crycb_aqm(vm);
>>> +        if (!bitmap_and(aqm, aqm, matrix->aqm, matrix->aqm_max + 1))
>>> +            continue;
>>> +
>>> +        for_each_set_bit_inv(apid, apm, matrix->apm_max + 1)
>>> +            for_each_set_bit_inv(apqi, aqm, matrix->aqm_max + 1)
>>> +                kvm_ap_log_sharing_err(vm, apid, apqi);
>>> +
>>> +        return -EBUSY;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +int kvm_ap_configure_matrix(struct kvm *kvm, struct kvm_ap_matrix 
>>> *matrix)
>>> +{
>>> +    int ret = 0;
>>> +
>>> +    mutex_lock(&kvm->lock);
>>
>> You seem to take only kvm->lock, vm_list however (used in
>> kvm_ap_validate_queue_sharing()) seems to be protected by
>> kvm_lock.
>>
>> Can you tell me why is this supposed to be safe?
>>
>> What is supposed to prevent an execution like
>> vm1: call kvm_ap_configure_matrix(m1)
>> vm2: call kvm_ap_configure_matrix(m2)
>> vm1: call kvm_ap_validate_queue_sharing(m1)
>> vm2: call kvm_ap_validate_queue_sharing(m2)
>> vm1: call kvm_ap_set_crycb_masks(m1)
>> vm2: call kvm_ap_set_crycb_masks(m2)
>>
>> where, let's say, m1 and m2 are equal in the sense that the
>> mask values are the same?
>
> vm1 will get the kvm->lock first in your scenario when
> kvm_ap_configure_matrix(m1) is invoked. Since the other
> functions - i.e., kvm_ap_validate_queue_sharing(m1) and
> kvm_ap_set_crycb_masks(m1) - are static and only called
> from the kvm_ap_configure_matrix(m1), your scenario
> can never happen because vm2 will not get the lock until
> kvm_ap_configure_matrix(m1) has completed. I see your
> point, however, and maybe I should also acquire the kvm_lock.

AFAIU the locks you are talking about are KVM specific
but the example from Halil use two different VM,
i.e. two different locks are used and vm2 never wait for vw1.

>
>>
>>
>> Regards,
>> Halil
>>
>>> +
>>> +    ret = kvm_ap_validate_queue_sharing(kvm, matrix);
>>> +    if (ret)
>>> +        goto done;
>>> +
>>> +    kvm_ap_set_crycb_masks(kvm, matrix);
>>> +
>>> +done:
>>> +    mutex_unlock(&kvm->lock);
>>> +
>>> +    return ret;
>>> +}
>>> +EXPORT_SYMBOL(kvm_ap_configure_matrix);
>>> +
>
>

-- 
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany