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]
Message-Id: <3fedbde5-ef83-c67e-6352-fd492f258009@linux.ibm.com>
Date:   Fri, 1 Mar 2019 13:03:40 +0100
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     Christian Borntraeger <borntraeger@...ibm.com>,
        Tony Krowiak <akrowiak@...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 28/02/2019 15:14, Pierre Morel wrote:
> On 28/02/2019 14:52, Cornelia Huck wrote:
>> On Thu, 28 Feb 2019 14:16:09 +0100
>> Pierre Morel <pmorel@...ux.ibm.com> wrote:
>>
>>> On 28/02/2019 12:22, Cornelia Huck wrote:
>>
>>>> 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.
>>
>> Ah, ok; so each case (that we want to handle) should call into a
>> subhandler that does
>> {
>>     (... check things like facilities ...)
>>     if (!specific_hook)
>>         inject_specif_excp_and_return();
>>     ret = specific_hook();
>>     if (ret)
>>         set_resp_code_0x01(); // or in specific_hook()?
>> }
>>
>> ?
> 
> Yes something in this direction.

Sorry, after reflection, no, we do not want to change the previous 
behavior so we only handle the AQIC case.

Regards,
Pierre


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ