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: <13331f80-8821-6de3-ca29-7a3ea869e4f1@linux.vnet.ibm.com>
Date:   Wed, 16 May 2018 09:12:48 -0400
From:   Tony Krowiak <akrowiak@...ux.vnet.ibm.com>
To:     pmorel@...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 05/16/2018 03:48 AM, Pierre Morel wrote:
> On 15/05/2018 18:07, Tony Krowiak wrote:
>> On 05/15/2018 10:55 AM, Pierre Morel wrote:
>>> On 07/05/2018 17:11, 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:
>>>>
> ...snip...
>>>> +}
>>>
>>> This function (ap_validate_queue_sharing) only verifies that VM 
>>> don't share queues.
>>> What about the queues used by a host application?
>>
>> How can that be verified from this function? I suppose I could put a 
>> check in here to
>> verify that the queues are reserved by the vfio_ap device driver, but 
>> that would
>> be redundant because an AP queue can not be assigned to a mediated 
>> matrix device
>> via its sysfs attributes unless it is reserved by the vfio_ap device 
>> driver (see
>> patches 7, 8 and 9).
>>
>>>
>>>
>>> I understand that you want to implement  these checks within KVM but 
>>> this is
>>> related to which queue devices are bound to the matrix and which one 
>>> are not.
>>
>> See my comments above and below about AP queue assignment to the 
>> mediated matrix
>> device. The one verification we can't do when the devices are 
>> assigned is whether
>> another guest is using the queue because assignment occurs before the 
>> guest using
>> the queue is started in which case we have no access to KVM. It makes 
>> no sense to
>> do so at assignment time anyway because it doesn't matter until the 
>> guest using
>> the mediated matrix device is started, so that check is done in KVM.
>>
>>>
>>>
>>> I think that this should be related somehow to the bounded queue 
>>> devices and
>>> therefor implemented inside the matrix driver.
>>
>> As I stated above, when an AP queue is assigned to the mediated 
>> matrix device via
>> its sysfs attributes, a check is done to verify that it is bound to 
>> the vfio_ap
>> device driver (see patches 7, 8 and 9). If not, then assignment will 
>> be rejected;
>> therefore, it will not be possible to configure a CRYCB with AP 
>> queues that are
>> not bound to the device driver.
>
> This patch and te followed patches take care that the queues are bound 
> to the
> matrix driver when they are assigned to the matrix using the sysfs 
> entries.
>
> But they do not take care that the queue can not be unbound before you 
> start
> the guest, and they are not in the path if the admin decide to unbind 
> a queue
> at some later time.

That is a good point. I need to put a check in the device driver at the time
the mediated device fd is opened to verify that the queues being 
configured in
the guest's CRYCB are bound to the driver.

>
>
>>
>>>
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>
>