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:22:51 +0100
From:   Cornelia Huck <cohuck@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.com>
Cc:     Tony Krowiak <akrowiak@...ux.ibm.com>, pmorel@...ux.ibm.com,
        alex.williamson@...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 Thu, 28 Feb 2019 12:03:38 +0100
Christian Borntraeger <borntraeger@...ibm.com> wrote:

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

So, to summarize, the function should do:
- Is userspace supposed to emulate everything (!ECA_APIE)? Return
  -EOPNOTSUPP to hand control to it.
- We are now interpreting the instruction in KVM. Do common checks
  (PSTATE etc.) and inject exceptions, if needed.
- Now look at the fc; if there's a handler for it, call that; if not
  (case does not attempt to call a specific handler, or no handler
  registered), inject a specification exception. (Do we want pre-checks
  like for facility 65 here, or in the handler?)

That response code 0x01 thingy probably needs to go into the specific
handler function, if anywhere (don't know the semantics, sorry).

Question: Will the handlers for the individual fcs need to generate
different exceptions on their own? I.e., do they need to do injections
themselves, or should the calling function possibly inject an exception
on error?

(Are there more possible fcs than 0x3 and whatever the other
subfunction was?)