linux-kernel - Re: [PATCH v7 03/15] 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:   Tue, 28 Apr 2020 10:09:09 +0200
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...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,
        jjherne@...ux.ibm.com, fiuczy@...ux.ibm.com
Subject: Re: [PATCH v7 03/15] s390/zcrypt: driver callback to indicate
 resource in use



On 2020-04-28 00:24, Tony Krowiak wrote:
> 
> 
> On 4/27/20 4:20 AM, Pierre Morel wrote:
>>
>>
>> On 2020-04-07 21:20, Tony Krowiak wrote:
>>> Introduces a new driver callback to prevent a root user from unbinding
>>> an AP queue from its device driver if the queue is in use. The intent of
>>> this callback is to provide a driver with the means to prevent a root 
>>> user
>>> from inadvertently taking a queue away from a guest and giving it to the
>>> host while the guest is still using it.

...snip...

>>
>> This functionality is valid for the host as for the guests and is 
>> handled automatically by the firmware with the CRYCB.
>> The AP bus uses QCI to retrieve the host CRYCB and build the hosts AP 
>> queues.
>>
>> If instead to mix VFIO CRYCB matrix handling and queues at the same 
>> level inside the AP bus we separate these different firmware entities 
>> in two different software entities.
>>
>> If we make the AP bus sit above a CRYCB/Matrix bus, and in the way 
>> virtualize the QCI and test AP queue instructions:
>> - we can directly pass a matrix device to the guest though a VFIO 
>> matrix device
>> - the consistence will be automatic
>> - the VFIO device and parent device will be of the same kind which 
>> would make the design much more clearer.
>> - there will be no need for these callback because the consistence of 
>> the matrix will be guaranteed by firmware
> 
> As stated in my response above, the issue here is not consistency. While 
> the design you describe
> may be reasonable, it is a major departure from what is out in the 
> field. In other words, that ship
> has sailed.


The current VFIO-AP driver works as before, without any change, above 
the Matrix device I suggest.

Aside the old scheme which can continue, the Matrix device can be used 
directly to build a VFIO Matrix device, usable by QEMU without any 
modification.

Once the dynamic extensions proposed in this series and the associated 
tools are out on the field, then yes the ship is really far.
For now, the existing user's API do not change, the existing tools do 
not need modifications and we can repair the ship for its long journey.

The inconsistency between device and VFIO device and the resulting 
complexity is not going to ease future enhancement.

Regards,
Pierre



-- 
Pierre Morel
IBM Lab Boeblingen