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
| ||
|
Date: Thu, 2 Nov 2017 14:49:12 -0400 From: Tony Krowiak <akrowiak@...ux.vnet.ibm.com> To: Christian Borntraeger <borntraeger@...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 11:53 AM, Christian Borntraeger wrote: > > 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. The ECA.28 bit controls whether instructions are intercepted or interpreted - i.e., handled via hardware virtualization. If set, as is done in patch2, then instructions will be interpreted. I don't see how that affects enabling or disabling AP instructions, unless we don't set ECA.28, intercept every instruction and program check. Am I missing something here? >
Powered by blists - more mailing lists