linux-kernel - Re: [PATCH v4 1/7] s390: ap: kvm: add PQAP interception for AQIC

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:   Thu, 28 Feb 2019 12:03:38 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>, pmorel@...ux.ibm.com
Cc:     alex.williamson@...hat.com, cohuck@...hat.com,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, frankja@...ux.ibm.com, pasic@...ux.ibm.com,
        david@...hat.com, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, freude@...ux.ibm.com, mimu@...ux.ibm.com
Subject: Re: [PATCH v4 1/7] s390: ap: kvm: add PQAP interception for AQIC



On 28.02.2019 10:42, Christian Borntraeger wrote:
[...]
>> Okay, let's go back to the genesis of this discussion; namely, my
>> suggestion about moving the fc == 0x03 check into the hook code. If
>> the vfio_ap module is not loaded, there will be no hook code. In that
>> case, the check for the hook will fail and ultimately response code
>> 0x01 will be set in the status word (which may not be the right thing
>> to do?). You have not stated a single good reason for keeping this
>> check, but I'm done with this silly argument. It certainly doesn't
>> hurt anything.
> 
> The instruction handler must handle the basic checks for the
> instruction itself as outlined above.
> 
> Do we want to allow QEMU to fully emulate everything (the  ECA_APIE case being off)?
> The we should pass along everything to QEMU, but this is already done with the
> ECA_APIE check, correct?
> 
> Do we agree that when we are beyond the ECA_APIE check, that we do not emulate
> in QEMU and we have enabled the AP instructions interpretion?
> If yes then this has some implication:
> 
> 1. ECA is on and we should only get PQAP interception for specific FC (namely 3).
> 2. What we certainly should check is the facility bit of the guest (65) and reject fc==3
> right away with a specification exception. I do not want the hook to mess with
> the kvm cpu model. @Pierre would be good to actually check test_kvm_facility(vcpu->kvm, 65))
> 3. What shall we do when fc == 0x3? We can certainly do the check here OR in the
> hook. As long as we have only fc==3 this does not matter.
> 
> Correct?

Thinking more about that, I think we should inject a specification exception for all
unknown FCc != 0x3. That would also qualify for keeping it in the instruction handler.