Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1814287pxb; Wed, 9 Feb 2022 05:11:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGk/FYS2WrSD81SNTiAzyLFmEDDcRkZSviDHprWTN7aBzP38EbgqCRmBFuntnQoesQHh80 X-Received: by 2002:a17:902:bf06:: with SMTP id bi6mr2059765plb.24.1644412300978; Wed, 09 Feb 2022 05:11:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644412300; cv=none; d=google.com; s=arc-20160816; b=ApdOSLDgi+ZYDr9UitjmWJ+knIK8S8/QwWaHmW7+BediYl91G+1yARat7QTcJjB/8S N0YVQ1TGhTzddh4SCbWE9RvqWQ17txZLigH+mjiHAfHlHYRS7jhBBElKeGxbKLcbNhlw nobZYHODUV9v8tvgMx+ootEoXA1UFfphdb/6HvLVdGzDe/jqQbi8KtejcIeGnH1XTsDk UhxWuE60HA/6vbp0u8Cxb8CK9yzdUxNyOhsV7U1HK2qqu/Vz8h3lJ27FGIv2/rqGrUVj cc3FjTFhYddrOXM4suXvvxKfxG4DThfJj9S3UzdRFmm6F8AyTm8gJVYyTlTx6XS9HCsO Voxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=0SulrBNmeN84wRgtYofE4OjmbcUym9l2eOVo7XxUFm4=; b=cCiL9sh/M9y+IxWcSim9VUa/yl9jnfpvUDbptbUnljvyyG9eT6aS3te7mbgdWOtibQ OELKFtdH6POsCeJgXCe+mJ+uYLCfUa5qkWjOPElG3wDWkKjGs8wKR9/lvzbjnAcpRSXs yELM/rIDUI/2ia/A4vgGDj1SMb9whY58a7dB8R/pZjRORGnzv0Sncz7Z22EgMbzSO52C AZ1kJZNpfmV8OsiqkSmxdm/RhKancuQhYnJuV+8CxfritvEwnXzvsFyWw+W3GYS3dFke dB/5/krgpso9pZd1vQf7WVsOXoasljEiWh4IBn7pAtEcifKwYZ4N34fninDG+iL83SES yEEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TeHVbBMK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id oj2si5295358pjb.91.2022.02.09.05.11.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 05:11:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TeHVbBMK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8038BE17ECE9; Wed, 9 Feb 2022 02:37:11 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231911AbiBIKFf (ORCPT + 99 others); Wed, 9 Feb 2022 05:05:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231954AbiBIKFN (ORCPT ); Wed, 9 Feb 2022 05:05:13 -0500 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66AE1E0F61CA; Wed, 9 Feb 2022 02:05:07 -0800 (PST) Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 2199wVnY006620; Wed, 9 Feb 2022 10:02:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=0SulrBNmeN84wRgtYofE4OjmbcUym9l2eOVo7XxUFm4=; b=TeHVbBMKiV+8IdYckMbtnl6E6+YYCUp86qKBJW4MG4rk8ZslXSb7CJ6505HNrwO2r34a he6sCzDC75b7JgP2k7/sxGc2ytQ1LIGgnjaR92GhdMtMvaivRkNWWmMRiwirLfyaHaiW kYu5QlghfS/iiEoxOGHrUYNGwF24vAcdi+WHZdghVRhSJeQ+aoJyZ9xpd+IY+pwiBvsB NINh1fhxATE9DOvVcCLBrb6rqEuR4vSPQFy9nKoEXx4KAYjKCrdy2WBCp7F4ivvsZRmi +hfeKf87ceiJv23Mrbrnd7thbAKKTb0krNiGjdH85JYKIaFoh7DtJfeZIsJruzPs54UC Mw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3e4ajk974d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Feb 2022 10:02:00 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 2199ueU2000690; Wed, 9 Feb 2022 10:01:59 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 3e4ajk973e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Feb 2022 10:01:59 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2199p0jZ011025; Wed, 9 Feb 2022 10:01:57 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma04fra.de.ibm.com with ESMTP id 3e2ygqb2md-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Feb 2022 10:01:57 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 219A1qJ236176188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Feb 2022 10:01:52 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3BD6552076; Wed, 9 Feb 2022 10:01:52 +0000 (GMT) Received: from li-7e0de7cc-2d9d-11b2-a85c-de26c016e5ad.ibm.com (unknown [9.171.75.42]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id A0E3052069; Wed, 9 Feb 2022 10:01:51 +0000 (GMT) Message-ID: <8d502356c3a624847c0dd2fe5d5f60e72923a141.camel@linux.ibm.com> Subject: Re: [PATCH v2 05/11] KVM: s390: Add optional storage key checking to MEMOP IOCTL From: Janis Schoetterl-Glausch To: Christian Borntraeger , Heiko Carstens , Janosch Frank Cc: Alexander Gordeev , Claudio Imbrenda , David Hildenbrand , Jonathan Corbet , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Paolo Bonzini , Sven Schnelle , Vasily Gorbik Date: Wed, 09 Feb 2022 11:01:51 +0100 In-Reply-To: <6ea27647-fbbe-3962-03a0-8ca5340fc7fd@linux.ibm.com> References: <20220207165930.1608621-1-scgl@linux.ibm.com> <20220207165930.1608621-6-scgl@linux.ibm.com> <48d1678f-746c-dab6-5ec3-56397277f752@linux.ibm.com> <71f07914-d0b2-e98b-22b2-bc05f04df2da@linux.ibm.com> <6ea27647-fbbe-3962-03a0-8ca5340fc7fd@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2oY2-tmZHD_Sxpy4wQ698-wD40BPGqHS X-Proofpoint-GUID: 3k6cMY92IgRBtWlRi49vOeHsyo1vvYAn X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-09_05,2022-02-09_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 priorityscore=1501 phishscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202090064 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > Acked-by: Janosch Frank > > > > Reviewed-by: Claudio Imbrenda > > > > --- > > > > 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 > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > @@ -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. Maybe a comment is good enought? > > > Patch 6 has the same issue in the vm ioctl handler. > > > Simply use mop->key and mop->ar below and get rid of the local variables. > > > The structure has no concurrency and gcc will handle that just as the local variable. > > > > > > Other than that this looks good. > > > > [...] > >