Date:   Wed, 9 Feb 2022 14:11:13 +0100
From:   Christian Borntraeger <borntraeger@...ux.ibm.com>
To:     Janis Schoetterl-Glausch <scgl@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>
Cc:     Alexander Gordeev <agordeev@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        David Hildenbrand <david@...hat.com>,
        Jonathan Corbet <corbet@....net>, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v2 05/11] KVM: s390: Add optional storage key checking to
 MEMOP IOCTL



Am 09.02.22 um 14:08 schrieb Janis Schoetterl-Glausch:
> On 2/9/22 13:11, Christian Borntraeger wrote:
>>
>>
>> Am 09.02.22 um 12:04 schrieb Janis Schoetterl-Glausch:
>>> On Wed, 2022-02-09 at 11:48 +0100, Christian Borntraeger wrote:
>>>>
>>>> Am 09.02.22 um 11:39 schrieb Janis Schoetterl-Glausch:
>>>>> On 2/9/22 11:08, Christian Borntraeger wrote:
>>>>>>
>>>>>> Am 09.02.22 um 11:01 schrieb Janis Schoetterl-Glausch:
>>>>>>> On Wed, 2022-02-09 at 10:08 +0100, Christian Borntraeger wrote:
>>>>>>>> Am 09.02.22 um 09:49 schrieb Janis Schoetterl-Glausch:
>>>>>>>>> On 2/9/22 08:34, Christian Borntraeger wrote:
>>>>>>>>>> Am 07.02.22 um 17:59 schrieb Janis Schoetterl-Glausch:
>>>>>>>>>>> User space needs a mechanism to perform key checked accesses when
>>>>>>>>>>> emulating instructions.
>>>>>>>>>>>
>>>>>>>>>>> The key can be passed as an additional argument.
>>>>>>>>>>> Having an additional argument is flexible, as user space can
>>>>>>>>>>> pass the guest PSW's key, in order to make an access the same way the
>>>>>>>>>>> CPU would, or pass another key if necessary.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Janis Schoetterl-Glausch <scgl@...ux.ibm.com>
>>>>>>>>>>> Acked-by: Janosch Frank <frankja@...ux.ibm.com>
>>>>>>>>>>> Reviewed-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
>>>>>>>>>>> ---
>>>>>>>>>>>        arch/s390/kvm/kvm-s390.c | 49 +++++++++++++++++++++++++++++++---------
>>>>>>>>>>>        include/uapi/linux/kvm.h |  8 +++++--
>>>>>>>>>>>        2 files changed, 44 insertions(+), 13 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>>>>>>>>> index cf347e1a4f17..71e61fb3f0d9 100644
>>>>>>>>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>>>>>>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>>>>>>>>>> @@ -32,6 +32,7 @@
>>>>>>>>>>>        #include <linux/sched/signal.h>
>>>>>>>>>>>        #include <linux/string.h>
>>>>>>>>>>>        #include <linux/pgtable.h>
>>>>>>>>>>> +#include <linux/bitfield.h>
>>>>>>>>>>>          #include <asm/asm-offsets.h>
>>>>>>>>>>>        #include <asm/lowcore.h>
>>>>>>>>>>> @@ -2359,6 +2360,11 @@ static int kvm_s390_handle_pv(struct kvm *kvm, struct kvm_pv_cmd *cmd)
>>>>>>>>>>>            return r;
>>>>>>>>>>>        }
>>>>>>>>>>>        +static bool access_key_invalid(u8 access_key)
>>>>>>>>>>> +{
>>>>>>>>>>> +    return access_key > 0xf;
>>>>>>>>>>> +}
>>>>>>>>>>> +
>>>>>>>>>>>        long kvm_arch_vm_ioctl(struct file *filp,
>>>>>>>>>>>                       unsigned int ioctl, unsigned long arg)
>>>>>>>>>>>        {
>>>>>>>>>>> @@ -4687,34 +4693,54 @@ static long kvm_s390_guest_mem_op(struct kvm_vcpu *vcpu,
>>>>>>>>>>>                          struct kvm_s390_mem_op *mop)
>>>>>>>>>>>        {
>>>>>>>>>>>            void __user *uaddr = (void __user *)mop->buf;
>>>>>>>>>>> +    u8 access_key = 0, ar = 0;
>>>>>>>>>>>            void *tmpbuf = NULL;
>>>>>>>>>>> +    bool check_reserved;
>>>>>>>>>>>            int r = 0;
>>>>>>>>>>>            const u64 supported_flags = KVM_S390_MEMOP_F_INJECT_EXCEPTION
>>>>>>>>>>> -                    | KVM_S390_MEMOP_F_CHECK_ONLY;
>>>>>>>>>>> +                    | KVM_S390_MEMOP_F_CHECK_ONLY
>>>>>>>>>>> +                    | KVM_S390_MEMOP_F_SKEY_PROTECTION;
>>>>>>>>>>>        -    if (mop->flags & ~supported_flags || mop->ar >= NUM_ACRS || !mop->size)
>>>>>>>>>>> +    if (mop->flags & ~supported_flags || !mop->size)
>>>>>>>>>>>                return -EINVAL;
>>>>>>>>>>> -
>>>>>>>>>>>            if (mop->size > MEM_OP_MAX_SIZE)
>>>>>>>>>>>                return -E2BIG;
>>>>>>>>>>> -
>>>>>>>>>>>            if (kvm_s390_pv_cpu_is_protected(vcpu))
>>>>>>>>>>>                return -EINVAL;
>>>>>>>>>>> -
>>>>>>>>>>>            if (!(mop->flags & KVM_S390_MEMOP_F_CHECK_ONLY)) {
>>>>>>>>>>>                tmpbuf = vmalloc(mop->size);
>>>>>>>>>>>                if (!tmpbuf)
>>>>>>>>>>>                    return -ENOMEM;
>>>>>>>>>>>            }
>>>>>>>>>>> +    ar = mop->ar;
>>>>>>>>>>> +    mop->ar = 0;
>>>>>>>>>>
>>>>>>>>>> Why this assignment to 0?
>>>>>>>>>
>>>>>>>>> It's so the check of reserved below works like that, they're all part of the anonymous union.
>>>>>>>>
>>>>>>>> Ah, I see. This is ugly :-)
>>>>>>>
>>>>>>> Yes :)
>>>>>>>>>>> +    if (ar >= NUM_ACRS)
>>>>>>>>>>> +        return -EINVAL;
>>>>>>>>>>> +    if (mop->flags & KVM_S390_MEMOP_F_SKEY_PROTECTION) {
>>>>>>>>>>> +        access_key = mop->key;
>>>>>>>>>>> +        mop->key = 0;
>>>>>>>>>>
>>>>>>>>>> and this? I think we can leave mop unchanged.
>>>>>>>>>>
>>>>>>>>>> In fact, why do we add the ar and access_key variable?
>>>>>>>>>> This breaks the check from above (if (mop->flags & ~supported_flags || mop->ar >= NUM_ACRS || !mop->size))  into two checks
>>>>>>>>>> and it will create a memleak for tmpbuf.
>>>>>>>>>
>>>>>>>>> I can move the allocation down, goto out or get rid of the reserved check and keep everything as before.
>>>>>>>>> First is simpler, but second makes handling that case more explicit and might help in the future.
>>>>>>>>
>>>>>>>> Maybe add a reserved_02 field in the anon struct and check this for being zero and get rid of the local variables?
>>>>>>>
>>>>>>> I think that would require us adding new fields in the struct by putting them in a union with reserved_02 and so on,
>>>>>>> which could get rather messy.
>>>>>>
>>>>>> I think it is fine to rename reserved_02. Maybe rename that to dont_use_02 ?
>>>>>
>>>>> I don't know what kind of stability guarantees we give here, since it can only happen when recompiling with
>>>>> a new header. dont_use is a lot better than reserved here, after all we tell user space to set
>>>>> reserved bytes to 0, using reserved_02 to do that would be quite handy and therefore likely.
>>>>>
>>>>> The question is also what semantic we want for the check.
>>>>> The way it works right now, user space also needs to set unused fields to 0, e.g. key if the flag is not set.
>>>>> At least this is the case for the vm memop, the vcpu memop cannot do that because of backward compatibility.
>>>>
>>>> As an alternative just remove the check for reserved == 0 and do that later on as an add-on patch?
>>>
>>> That would kinda defeat the purpose of the check, since misbehaving user space programs would
>>> get an error then but not now.
>>
>>
>> As a matter of fact, we do not check today. What about the following.
> 
> We don't do it for the vcpu memop, but since we're newly introducing the vm memop we are free to decide what we want.
> It's purely about future proofing, e.g. we would have had the possibility to add the key checking feature without a flag,
> if the existing memop did the check. Committing ourselves to always adding a flag is fine by me, but I don't like the
> previous state of affairs, where user space should set reserved bytes to 0 but it's not enforced.
> 
>> 1. remove the checkreserved logic. its too complicated
>> 2. do not check for reserved to be zero
>> 4. state that the reserved fields are ignored without the appropriate flag
>> 5. add the necessary flag as comment to the fields
>> 6. check for unkmown flags and bail out
> 
> I'll implement this, except maybe 5, since the documentation covers that and the availability of the flags themselves
> is conditional on other factors.

Yes, 5 only where it makes sense.

Powered by blists - more mailing lists