linux-kernel - Re: [PATCH v10 11/26] s390: vfio-ap: implement mediated device open callback

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:   Mon, 24 Sep 2018 12:07:46 -0400
From:   Tony Krowiak <akrowiak@...ux.ibm.com>
To:     David Hildenbrand <david@...hat.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,
        frankja@...ux.ibm.com
Subject: Re: [PATCH v10 11/26] s390: vfio-ap: implement mediated device open
 callback

On 09/24/2018 04:40 AM, David Hildenbrand wrote:
> 
>>    /**
>> - * Verify that the AP instructions are available on the guest. This is
>> indicated
>> - * via the  KVM_S390_VM_CPU_FEAT_AP CPU model feature.
>> + * Verify that the AP instructions are being interpreted by firmware
>> for the
>> + * guest. This is indicated by the kvm->arch.crypto.apie flag.
>>     */
>>    static int kvm_ap_validate_crypto_setup(struct kvm *kvm)
>>    {
>> -	if (test_bit_inv(KVM_S390_VM_CPU_FEAT_AP, kvm->arch.cpu_feat))
>> +	if (kvm->arch.crypto.apie)
>>    		return 0;
> 
> I wonder if this check makes sense, because apie can be toggled during
> runtime. I guess it would be sufficient to check if the ap control block
> is available and apie is supported by the HW.

I am not clear about what you are getting at here, but I'll attempt
to respond. There is no need to check if the AP control block (CRYCB)
is available as the address is set in the CRYCBD three instructions
above, even if AP instructions are not available. Regarding whether apie 
is supported by the hardware, the value of vcpu->kvm->arch.crypto.apie 
can not be set unless it is supported by the HW. In the patch (24/26) 
that provides the VM attributes to toggle this value, it can only be 
turned on if the AP instructions are available. I might also note that 
the kvm_ap_validate_crypto_setup() function is called whenever one of 
the VM crypto attributes is changed, so it makes sense that decisions 
made in this function are based on a change to a VM crypto attribute. In 
my first pass at changing this function, I checked
ap_instructions_available() here, but after considering all of the
above, it made sense to me to check the apie flag.

> 
>