linux-kernel - Re: [PATCH 5/6] KVM: s390: wire up seb feature

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: <0a8dad23-0d88-cb10-d943-ac9ee265df7f@de.ibm.com>
Date:   Wed, 17 Jan 2018 12:28:27 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org
Cc:     Martin Schwidefsky <schwidefsky@...ibm.com>,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jon Masters <jcm@...hat.com>,
        Marcus Meissner <meissner@...e.de>,
        Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 5/6] KVM: s390: wire up seb feature



On 01/17/2018 12:22 PM, Paolo Bonzini wrote:
>> while this is kvm code, my current plan is to submit the "final"
>> version after review and probably some fixes/renames via Martin
>> together with the other patches.  Are you ok with that? Right now it
>> seems that the CAP number is still fine.
> Sure, though there will be a capability introduced by PPC for similar
> purposes, so check for conflicts.
> 
> On 17/01/2018 12:18, Christian Borntraeger wrote:
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 2c93cbb..0c18f73 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -421,6 +421,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>  	case KVM_CAP_S390_GS:
>>  		r = test_facility(133);
>>  		break;
>> +	case KVM_CAP_S390_SEB:
>> +		r = test_facility(82);
>> +		break;
>>  	default:
>>  		r = 0;
> 
> Can you add a generic "test facility" capability and ioctl?

The problem is not that I announce the facility, I in fact announce that the
programmatic interface is available (the sebc sync reg and the usage of that field).
(So the CAP is part of this patch to have both in lockstep)
A non-existing facility will then just disable that programmatic interface.