From: Pierre Morel <pmorel@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, borntraeger@de.ibm.com
Cc: linux-kernel@vger.kernel.org, cohuck@redhat.com,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
frankja@linux.ibm.com, akrowiak@linux.ibm.com,
pasic@linux.ibm.com, Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: [PATCH v1] KVM: s390: vsie: fix Do the CRYCB validation first
Date: Fri, 1 Feb 2019 14:37:30 +0100 [thread overview]
Message-ID: <3bb397e9-d679-1152-1b42-d633682b3272@linux.ibm.com> (raw)
In-Reply-To: <ccdc89cd-5299-e674-3329-74e9131dd874@redhat.com>
On 01/02/2019 11:56, David Hildenbrand wrote:
> On 01.02.19 10:52, Pierre Morel wrote:
>> The case when the SIE for guest3 is not setup for using
>> encryption keys nor Adjunct processor but the guest2
>> does use these features was not properly handled.
>>
>> This leads SIE entry for guest3 to crash with validity intercept
>> because the guest2, not having the use of encryption keys nor
>> Adjunct Processor did not initialize the CRYCB designation.
>>
>> In the case where none of ECA_APIE, ECB3_AES or ECB3_DEA
>> are set in guest3 a format 0 CRYCB is allowed for guest3
>> and the CRYCB designation in the SIE for guest3 is not checked
>> on SIE entry.
>>
>> Let's allow the CRYCD designation to be ignored when the
>> SIE for guest3 is not initialized for encryption key usage
>> nor AP.
>>
>> Fixup: d6f6959 (KVM: s390: vsie: Do the CRYCB validation first)
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
>> ---
>> arch/s390/kvm/vsie.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
>> index a153257..a748f76 100644
>> --- a/arch/s390/kvm/vsie.c
>> +++ b/arch/s390/kvm/vsie.c
>> @@ -300,6 +300,9 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>> if (!apie_h && !key_msk)
>> return 0;
>>
>> + if (!(scb_o->eca & ECA_APIE) && !(scb_o->ecb3 & (ECB3_AES | ECB3_DEA)))
>> + return 0;
>> +
>> if (!crycb_addr)
>> return set_validity_icpt(scb_s, 0x0039U);
>>
>>
>
> The original patch said
>
> "We need to handle the validity checks for the crycb, no matter what the
> settings for the keywrappings are. So lets move the keywrapping checks
> after we have done the validy checks."
>
> Can you explain why keywrapping now is important? These patches seem to
> contradict.
>
No it does not, having the flags set or not is part of the validity check.
but, I acted too fast.
The problem seems to be even clearer:
key_msk is defined as
int key_msk = test_kvm_facility(vcpu->kvm, 76);
If it is defined, as it should for a mask, as
(scb_o->ecb3 & (ECB3_AES | ECB3_DEA))
all is clear..., key_msk is not use but for this test, so I do not
understand why it is set as facility 76.
so I think I better do:
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index a153257..30843a8 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -289,7 +289,7 @@ static int shadow_crycb(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page)
unsigned long *b1, *b2;
u8 ecb3_flags;
int apie_h;
- int key_msk = test_kvm_facility(vcpu->kvm, 76);
+ int key_msk = scb_o->ecb3 & (ECB3_AES | ECB3_DEA);
int fmt_o = crycbd_o & CRYCB_FORMAT_MASK;
int fmt_h = vcpu->arch.sie_block->crycbd & CRYCB_FORMAT_MASK;
int ret = 0;
So just define a mask a mask.
I verify the functionality and test on Monday and if in between it
seems better to you so too I post the patch.
Thanks,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
next prev parent reply other threads:[~2019-02-01 13:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 9:52 [PATCH v1] KVM: s390: vsie: fix Do the CRYCB validation first Pierre Morel
2019-02-01 9:52 ` Pierre Morel
2019-02-01 10:50 ` Cornelia Huck
2019-02-01 13:36 ` Pierre Morel
2019-02-01 10:56 ` David Hildenbrand
2019-02-01 13:37 ` Pierre Morel [this message]
2019-02-04 14:48 ` Christian Borntraeger
2019-02-04 16:18 ` Pierre Morel
2019-02-04 15:15 ` David Hildenbrand
2019-02-04 16:17 ` Pierre Morel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3bb397e9-d679-1152-1b42-d633682b3272@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox