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]

Date:   Wed, 3 Apr 2019 14:09:14 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.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 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 ...

-- 

Thanks,

David / dhildenb