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  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 14:16:09 +0100
From:   Pierre Morel <>
To:     Cornelia Huck <>,
        Christian Borntraeger <>
Cc:     Tony Krowiak <>,,,,,,,,,,,
Subject: Re: [PATCH v4 1/7] s390: ap: kvm: add PQAP interception for AQIC

On 28/02/2019 12:22, Cornelia Huck wrote:
> On Thu, 28 Feb 2019 12:03:38 +0100
> Christian Borntraeger <> 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).

What do you mean with specific handler function?

If you mean a switch around the FC with static function's call, I agree, 
if you mean a jump into a hook I do not agree.

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

There are some specificities.

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

Yes, at least 5 different FC are implemented in the Linux kernel today 


Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

Powered by blists - more mailing lists