linux-kernel - Re: [PATCH v3 1/2] s390/setup: diag318: remove bit check and refactor struct

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: <dc195df9-3cee-3778-2375-51e9480e7aae@de.ibm.com>
Date:   Wed, 3 Apr 2019 14:10:38 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     David Hildenbrand <david@...hat.com>,
        Collin Walling <walling@...ux.ibm.com>, pbonzini@...hat.com,
        cohuck@...hat.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Cc:     schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
        frankja@...ux.ibm.com
Subject: Re: [PATCH v3 1/2] s390/setup: diag318: remove bit check and refactor
 struct



On 03.04.19 14:09, David Hildenbrand wrote:
> On 03.04.19 13:28, Christian Borntraeger wrote:
>>
>>
>> On 02.04.19 19:46, Collin Walling wrote:
>>> Execution of DIAGNOSE 0x318 is fenced by checking an SCLP bit
>>> for the availability of hardware support for the instruction.
>>>
>>> In order to support this instruction for a KVM/QEMU guest, we
>>> would need to provide modifications to the SCLP Read SCP Info
>>> data, which will in turn reduce the maximum number of CPUs that
>>> may be provided to the guest. This issue introduces compatability
>>> and legacy concerns.
>>>
>>> Let's circumvent this issue by removing the bit check and blindly
>>> executing the instruction. An exception table rule is in place to
>>> catch the case where hardware does not support this instruction.
>>
>>
>> No, please keep the check. We have to extend the read scp field anyway
>> for future extensions.
> 
> Wasn't there already an SCLP-way of telling the guest that the read-scp
> info response is bigger than 4k? Somehow rings a bell ...

Yes, that would be a future extension (the Linux guest does not support this).
Until then we probably have to go back to a smaller cpu number (e.g. 240 for 
machine type 4.1 and newer).