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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Nov 2017 16:53:16 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>, freude@...ibm.com
Cc:     linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, heiko.carstens@...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, qemu-s390x@...gnu.org,
        jjherne@...ux.vnet.ibm.com, thuth@...hat.com,
        pasic@...ux.vnet.ibm.com
Subject: Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest



On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
>>
>> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>>> On Fri, 13 Oct 2017 13:39:04 -0400
>>> Tony Krowiak <akrowiak@...ux.vnet.ibm.com> wrote:
>>>
>>>> Sets up the following facilities bits to enable the specified AP
>>>> facilities for the guest VM:
>>>>     * STFLE.12: Enables the AP Query Configuration Information
>>>>                 facility. The AP bus running in the guest uses
>>>>                 the information returned from this instruction
>>>>                 to configure AP adapters and domains for the
>>>>                 guest machine.
>>>>     * STFLE.15: Indicates the AP facilities test is available.
>>>>                 The AP bus running in the guest uses the
>>>>                 information.
>>>>
>>>> Signed-off-by: Tony Krowiak <akrowiak@...ux.vnet.ibm.com>
>>>> ---
>>>>  arch/s390/tools/gen_facilities.c |    2 ++
>>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
>>>> index 70dd8f1..eeaa7db 100644
>>>> --- a/arch/s390/tools/gen_facilities.c
>>>> +++ b/arch/s390/tools/gen_facilities.c
>>>> @@ -74,8 +74,10 @@ struct facility_def {
>>>>  			8,  /* enhanced-DAT 1 */
>>>>  			9,  /* sense-running-status */
>>>>  			10, /* conditional sske */
>>>> +			12, /* AP query configuration */
>>>>  			13, /* ipte-range */
>>>>  			14, /* nonquiescing key-setting */
>>>> +			15, /* AP special-command facility */
>>>>  			73, /* transactional execution */
>>>>  			75, /* access-exception-fetch/store indication */
>>>>  			76, /* msa extension 3 */
>>> With this all KVM guests will always have the AP instructions available, no?
>>> In principles I like this approach, but it differs from the way z/VM does things,
>>> there the guest will get an exception if it tries to execute an AP instruction
>>> if there are no AP devices assigned to the guest. I wonder if there is a reason
>>> why z/VM does it the way it does.
>> A good question. For LPAR it seems that you have AP instructions even if you have
>> no crypto cards.
>>
> I don't believe these facilities control whether or not AP instructions will be available
> 
> to the guest.

This is actually handled by your patch2 enabling the ECA bit.
I think we must decide if we want to be able to disable these instructions
via the cpu model. If yes we must then couple the facilities with the enablement.

Powered by blists - more mailing lists