From: Pierre Morel <pmorel@linux.ibm.com>
To: David Hildenbrand <david@redhat.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,
borntraeger@de.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com
Subject: Re: [PATCH v2 5/5] KVM: s390: vsie: Do the CRYCB validation first
Date: Thu, 23 Aug 2018 10:01:22 +0200 [thread overview]
Message-ID: <ea1dad6d-a698-5d0d-2c41-c08c46068e96@linux.ibm.com> (raw)
In-Reply-To: <18c65e67-c5e6-9c2f-e7ab-962376427369@redhat.com>
On 23/08/2018 09:31, David Hildenbrand wrote:
> On 23.08.2018 09:17, Pierre Morel wrote:
>> On 22/08/2018 19:15, David Hildenbrand wrote:
>>> On 22.08.2018 18:51, Pierre Morel wrote:
>>>> When entering the SIE the CRYCB validation better
>>>> be done independently of the instruction's
>>>> availability.
>>>>
>>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>>>> ---
>>>> arch/s390/kvm/vsie.c | 11 ++++++-----
>>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
>>>> index 7ee4329..fca25aa 100644
>>>> --- a/arch/s390/kvm/vsie.c
>>>> +++ b/arch/s390/kvm/vsie.c
>>>> @@ -164,17 +164,18 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>>> /* format-1 is supported with message-security-assist extension 3 */
>>>> if (!test_kvm_facility(vcpu->kvm, 76))
>>>> return 0;
>>>> - /* we may only allow it if enabled for guest 2 */
>>>> - ecb3_flags = scb_o->ecb3 & vcpu->arch.sie_block->ecb3 &
>>>> - (ECB3_AES | ECB3_DEA);
>>>> - if (!ecb3_flags)
>>>> - return 0;
>>>>
>>>> if ((crycb_addr & PAGE_MASK) != ((crycb_addr + 128) & PAGE_MASK))
>>>> return set_validity_icpt(scb_s, 0x003CU);
>>>> if (!crycb_addr)
>>>> return set_validity_icpt(scb_s, 0x0039U);
>>>>
>>>> + /* we may only allow it if enabled for guest 2 */
>>>> + ecb3_flags = scb_o->ecb3 & vcpu->arch.sie_block->ecb3 &
>>>> + (ECB3_AES | ECB3_DEA);
>>>> + if (!ecb3_flags)
>>>> + return 0;
>>>> +
>>>> /* copy only the wrapping keys */
>>>> if (read_guest_real(vcpu, crycb_addr + 72,
>>>> vsie_page->crycb.dea_wrapping_key_mask, 56))
>>>>
>>>
>>> That makes sense, especially if ECB3_AES is used but effectively turned
>>> off by us.
>>>
>>> What is the expected behavior if ECB3_AES | ECB3_DEA are not set by g2
>>> for g3?
>>>
>>
>> The use of functions PCKMO-Encrypt-DEA/AES induce a specification error.
>>
>> However other MSA3 function will continue to be usable.
>
> No, I meant which checks should be performed here.
The SIE should check the validity of the CRYCB.
However since we do not copy the key masks we do not
expect any access error on crycb_o
So it is more a philosophical problem, should the
hypervizor enforce an error here to act as the firmware?
regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
next prev parent reply other threads:[~2018-08-23 8:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-22 16:51 [PATCH v2 0/5] KVM: s390: vsie: Consolidate CRYCB validation Pierre Morel
2018-08-22 16:51 ` [PATCH v2 1/5] KVM: s390: vsie: BUG correction by shadow_crycb Pierre Morel
2018-08-22 16:53 ` David Hildenbrand
2018-08-23 6:40 ` Pierre Morel
2018-08-23 7:27 ` Cornelia Huck
2018-08-23 8:03 ` Pierre Morel
2018-08-23 8:02 ` Janosch Frank
2018-08-23 8:08 ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 2/5] KVM: s390: vsie: Only accept FORMAT1 CRYCB for guest2 Pierre Morel
2018-08-22 16:55 ` David Hildenbrand
2018-08-23 7:42 ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 3/5] KVM: s390: vsie: Allow support for a host without AP Pierre Morel
2018-08-22 17:06 ` David Hildenbrand
2018-08-23 6:44 ` Pierre Morel
2018-08-23 7:15 ` David Hildenbrand
2018-08-23 7:54 ` Pierre Morel
2018-08-23 6:52 ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 4/5] KVM: s390: vsie: Always test the crycbd for NULL Pierre Morel
2018-08-22 17:07 ` David Hildenbrand
2018-08-23 6:57 ` Pierre Morel
2018-08-22 16:51 ` [PATCH v2 5/5] KVM: s390: vsie: Do the CRYCB validation first Pierre Morel
2018-08-22 17:15 ` David Hildenbrand
2018-08-23 7:17 ` Pierre Morel
2018-08-23 7:31 ` David Hildenbrand
2018-08-23 8:01 ` Pierre Morel [this message]
2018-08-23 8:34 ` Janosch Frank
2018-08-23 8:40 ` David Hildenbrand
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=ea1dad6d-a698-5d0d-2c41-c08c46068e96@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=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=schwidefsky@de.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