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, 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ