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:   Thu, 7 Jun 2018 10:33:43 -0400
From:   Tony Krowiak <akrowiak@...ux.vnet.ibm.com>
To:     Halil Pasic <pasic@...ux.ibm.com>, 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 10/13] s390: vfio-ap: sysfs interface to view matrix
 mdev matrix

On 06/07/2018 09:16 AM, Halil Pasic wrote:
>
>
> On 06/07/2018 02:53 PM, Tony Krowiak wrote:
>>>>> 2) As I said above, what you show is not the effective mask used 
>>>>> by the guest
>>>>
>>>> Why would a sysfs attribute for the mediated matrix device show the 
>>>> effective
>>>> mask used by the guest?
>>>
>>> OK, bad word, "effective", replace with "really".
>>>
>>> We do not implement any kind of provisioning nor do we implement update
>>> of the CRYCB at any point after the first mediated device open.
>>
>> I think this is a way we might be able to hot plug/unplug devices.
>>
>>>
>>>
>>> Binding a queue and updating the mask can be done at any time (may 
>>> be we should change this ?)
>>
>> As I said above, I think we can utilize this as a means of hot 
>> plugging/unplugging AP
>> adapters and domains. If the guest is running when an adapter or 
>> domain is assigned,
>> we can update the guest's CRYCB at that time.
>>
>>>
>>>
>>> What is the point of showing a matrix which will never be used by 
>>> the guest?
>>
>> That is simply not true. The matrix WILL be used by a guest the next time a 
>>
>> guest is configured with a vfio-ap device referencing the path to the
>> mediated matrix device - i.e., -device vfio-ap,sysfsdev=$PATH. The point
>> is to show the matrix assigned to the mediated matrix device. In my 
>> mind, the
>> mediated matrix device is a separate object from the guest. Sure it is used 
>>
>> to configure a guest's matrix when the guest is started, but it could 
>> be used
>> to configure the matrix for any guest; it has no direct connection to a
>> particular guest until a guest using the device is started. IMHO the sysfs 
>>
>> attributes for the mediated matrix device reflect only the attributes of
>> the device, not the attributes of a guest.
>
> So bottom line is what? Is the interface going to change so that 
> modifications
> to the mdev's matrix will be reflected immediately -- to support 
> hotplug of
> domains and ap cards?
>
>
> Or are you intending to keep the interface as is?


I have been looking in to hot plug/unplug. I am in the exploratory phase and
have not yet come up with a concrete plan, but I believe we will be able to
hot plug/unplug adapters and domains using the sysfs attributes interfaces
for the mediated matrix device.

>
>
> If the matrix assigned to the mediated device can differ from the matrix
> of the guest (that is the masks in the CRYCB, and I'm talking about a 
> running
> guest) do you provide a way for the host admin to examine the matrix 
> of the
> guest? If not, why do you think that information is irrelevant to the 
> host
> admin?

I never said the information contained in the CRYCB is irrelevant to the 
host
admin. What I said was that the sysfs attributes apply to the mediated 
device,
not the guest. There may or may not be a guest using the mediated device at
any given point in time. I do not currently provide a way to examine the 
matrix
of the guest. I'm not sure whether a sysfs attribute of the mediated
device is the appropriate venue for displaying what's in the guest's CRYCB.
I suppose we could use the mediated device matrix attribute for this purpose
if you and Pierre insist, but I think we still need to
display the matrix or devices configured for the mediated device. It 
does beg
the question, are there interfaces an admin can use to display all of 
the other
devices being used by a guest? The only surefire way to see which AP devices
are actually used by the guest is to execute lszcrypt on the guest itself.

>
>
> Regards,
> Halil


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ