linux-kernel - Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization

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, 10 Jul 2018 10:49:08 +0200
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     Halil Pasic <pasic@...ux.ibm.com>,
        Tony Krowiak <akrowiak@...ux.vnet.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,
        Tony Krowiak <akrowiak@...ux.ibm.com>
Subject: Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP
 virtualization

On 09/07/2018 17:50, Halil Pasic wrote:
>
>
> On 07/09/2018 05:21 AM, Pierre Morel wrote:
>> On 03/07/2018 01:10, Halil Pasic wrote:
>>>
>>>
>>> On 06/29/2018 11:11 PM, Tony Krowiak wrote:
>>>> This patch provides documentation describing the AP architecture and
>>>> design concepts behind the virtualization of AP devices. It also
>>>> includes an example of how to configure AP devices for exclusive
>>>> use of KVM guests.
>>>>
>>>> Signed-off-by: Tony Krowiak <akrowiak@...ux.ibm.com>
>>>
>>> I don't like the design of external interfaces except for:
>>> * cpu model features, and
>>> * reset handling.
>>>
>>> In particular:
>>>
>>>
>> ...snip...
>>
>>> 4) If I were to act out the role of the administrator, I would 
>>> prefer to think of
>>> specifying or changing the access controls of a guest in respect to 
>>> AP (that is
>>> setting the AP matrix) as a single atomic operation -- which either 
>>> succeeds or fails.
>>>
>>> The operation should succeed for any valid configuration, and fail 
>>> for any invalid
>>> on.
>>>
>>> The current piecemeal approach seems even less fitting if we 
>>> consider changing the
>>> access controls of a running guest. AFAIK changing access controls 
>>> for a running
>>> guest is possible, and I don't see a reason why should we 
>>> artificially prohibit this.
>>>
>>> I think the current sysfs interface for manipulating the matrix is 
>>> good for
>>> manual playing around, but I would prefer having an interface that 
>>> is better
>>> suited for programs (e.g. ioctl).
>>
>> I disagree with using ioctl.
>
> Why? What speaks against ioctl?

Using a sysfs interface is easy and can be done using any interpreted 
language.
It has become the standard way to configure drivers.
Even the existing interface must be consolidated, it exist and is 
functional.


For what I understood, the problem is to have an atomic update of the 
matrix to avoid possible dead-lock
when two admin tasks try to configure a matrix for a guest.

The problematic is a userland problem it is not a kernel problem.

We have several possibilities to avoid this problem but  still keep a 
sysfs interface:
- the admin tasks may use a lock
- the admin task may use a policy like freeing owned resources if they 
can not get all resources.

Using a step by step configuration allows to easily know the missing 
resource in case of failure.

Regards,

Pierre


>
>> I agree that the current implementation is not right.
>> The configuration of APM and AQM should always be guarantied as coherent
>> within the host but it can be done doing the right checks when using 
>> the sysfs.
>>
>
> I'm glad we agree on this one at least.
>
> Regards,
> Halil


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