linux-kernel - Re: [PATCH 1/7] s390: zcrypt: driver callback to indicate resource in use

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:   Mon, 15 Apr 2019 18:43:24 -0400
From:   Tony Krowiak <akrowiak@...ux.ibm.com>
To:     Halil Pasic <pasic@...ux.ibm.com>
Cc:     Cornelia Huck <cohuck@...hat.com>,
        Harald Freudenberger <freude@...ux.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Reinhard Buendgen <buendgen@...ibm.com>,
        borntraeger@...ibm.com, frankja@...ux.ibm.com, david@...hat.com,
        schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
        pmorel@...ux.ibm.com, alex.williamson@...hat.com,
        kwankhede@...dia.com
Subject: Re: [PATCH 1/7] s390: zcrypt: driver callback to indicate resource in
 use

On 4/15/19 2:59 PM, Halil Pasic wrote:
> On Mon, 15 Apr 2019 12:51:23 -0400
> Tony Krowiak <akrowiak@...ux.ibm.com> wrote:
> 
>> Having said that, I understand your concern about a driver hogging
>> resources. I think I can provide a solution that serves both the
>> purpose of preventing problems associated with accidental removal
>> of AP resources as well as allowing root to remove them
>> forcefully. I'll work on that for v2.
> 
> Can you tell us some more about this solution? Should we stop reviewing
> v1 because v2 is going to be different anyway?

Patch 1 and 2 will be removed. There will not be a major design change
between these patches and v2. In order to avoid a long explanation of
my proposed changes, I'd prefer to state that the patch set will 
establish and enforce the following rules:

     1. An APQN can be assigned to an mdev device iff it is NOT
        reserved for use by a zcrypt driver and is not assigned to
        another mdev device.

     2. Once an APQN is assigned to an mdev device, it will remain
        assigned until it is explicitly unassigned.

     3. A queue's APQN can be set in the guest's CRYCB iff the APQN is
        assigned to the mdev device used by the guest; however, if the
        queue is also in the host configuration (i.e., online), it MUST
        also be bound to the vfio_ap device driver.

     4. When a queue is bound to the vfio_ap driver and its APQN
        is assigned to an mdev device in use by a guest, the guest will
        be given access to the queue.

     5. When a queue is unbound from the vfio_ap driver and its APQN
        is assigned to an mdev device in use by the guest, access to
        the card containing the queue will be removed from the guest.
        Keep in mind that we can not deny access to a specific queue
        due to the architecture (i.e., clearing a bit in the AQM
        removes access to the queue for all adapters)

     6. When an adapter is assigned to an mdev device that is in use
        by a guest, the guest will be given access to the adapter.

     7. When an adapter is unassigned from an mdev device that is in use
        by a guest, access to the adapter will removed from the guest.

     8. When a domain is assigned to an mdev device that is in use
        by a guest, the guest will be given access to the domain.

     9. When a domain is unassigned from an mdev device that is in use
        by a guest, access to the domain will removed from the guest.

> 
> Regards,
> Halil
>