Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1194443pxb; Fri, 21 Jan 2022 11:59:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJy1L7P3AY0zauNW6lFjbxPfTdt49ATtctW9RIOX/p3P5haFhgVu6nttAoojnpBjMi3zSNQk X-Received: by 2002:a63:3808:: with SMTP id f8mr3957643pga.186.1642795168796; Fri, 21 Jan 2022 11:59:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642795168; cv=none; d=google.com; s=arc-20160816; b=MjOepPA1n/MzFmMpOeac+gdrLN3s4Om8JWNQxg/I5B+5tHhr0j4ckp/bp2BChy/fT1 aHFdNp1Y5EwL9ADUcsWM67Fum0LOceTWrs5X8xPahxGRGZ4EmstmBquRMPJfni5U7fnQ 4+T6zuzZvwm6K7Vp4jza0ejMTneCQKCEz/P/1HsVd0C8jKK66bJe5pqNQvIiFNAnfchz k+H3UtDhlG6CrFX+rHiomzRW492M9O4YU+yazhgjTWOORJYny0IdaJTd0jSSq+YMU7e8 xXnd5nbc6E7nxrOWwAu4mkzbBneq2EuYuHw23R6E6hXyiU9hZpFP3XtLmVKiG0HRxeKY 3ymg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=82+shTmS4o0cfSrp/BPMR8f+Ux19g1x6eTQZujRGYDk=; b=CTgaHZXhO/acXgZwD6Gm4CSzaA+jfTHywoLz3qOO6l27hVILrutBieANgLDxL0QMps vcc4PYKNbiba8z8b7q7K+QJ6sPX8G+3+gbzjnPGgZntKdzB37sixVhsFt6JumKAaeen0 xkzqGZzjmmww45bD7kiJJFSAr6tHDRtZV5NfxwXLqJHMPpcnjHnp8RLmP0/QEov6n49S DPTW4at0tpTLSkoqHStDNoHboCOB+gKG6MGSC2nrcPlfxoxsL3Qch4bzDvEOTPUiN6KW wNN7U0NBoKWTQv0iEVBqjQtOqlyVVcpi6fFifyG9l9uKywvcpNRy/76GWwcv47SGkDHj ofcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TxPbqYQB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d11si7488510pgg.106.2022.01.21.11.59.16; Fri, 21 Jan 2022 11:59:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TxPbqYQB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240052AbiAST2C (ORCPT + 99 others); Wed, 19 Jan 2022 14:28:02 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:32472 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239940AbiAST14 (ORCPT ); Wed, 19 Jan 2022 14:27:56 -0500 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 20JIRqJh038377; Wed, 19 Jan 2022 19:27:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=82+shTmS4o0cfSrp/BPMR8f+Ux19g1x6eTQZujRGYDk=; b=TxPbqYQBCdjrMIo45lc1BbdzqRNp6b17nNAi6hYdn+/1EESogz6YlakQYmlR9K8DB6Vh i0ntwMCF+YeW1JYTkkLPjeMtueSYcz6moiAzu4/H8tRftic9tECgyOrK0QUkJLnngSee l9M8l3Gj2iN7EQIFT9WEyu7Y91DBLpPm9rNCeIlzNWT7zENb17T0LiMGHClim2/miUPj QgV50NKNIT4L3zfjkUpUMxVFf5JM2Ah6GtEGAqmQdH9Edk+IJbgt9LrN09o30ZhWiX3f sKhKJCTUivB9pHgP2bCsJVX6b0TIftOFx5V/MgaeeQwZHDhEO0tgOYAz6Bh7RMMRuk6s nA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dpqxsh208-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jan 2022 19:27:54 +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 20JJOEE4029666; Wed, 19 Jan 2022 19:27:54 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dpqxsh1yg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jan 2022 19:27:54 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 20JJHkEh024488; Wed, 19 Jan 2022 19:27:52 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma01fra.de.ibm.com with ESMTP id 3dknw9r52u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jan 2022 19:27:52 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 20JJRmxH31195590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jan 2022 19:27:49 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D26C6A405C; Wed, 19 Jan 2022 19:27:48 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5C67BA4060; Wed, 19 Jan 2022 19:27:48 +0000 (GMT) Received: from [9.171.34.112] (unknown [9.171.34.112]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 19 Jan 2022 19:27:48 +0000 (GMT) Message-ID: <1bbc2b03-6daa-5e27-956c-4d022bd8e9cb@linux.ibm.com> Date: Wed, 19 Jan 2022 20:27:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [RFC PATCH v1 02/10] KVM: s390: Honor storage keys when accessing guest memory Content-Language: en-US To: Janis Schoetterl-Glausch , Heiko Carstens , Vasily Gorbik , Janosch Frank , Alexander Gordeev , David Hildenbrand Cc: Claudio Imbrenda , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20220118095210.1651483-1-scgl@linux.ibm.com> <20220118095210.1651483-3-scgl@linux.ibm.com> From: Christian Borntraeger In-Reply-To: <20220118095210.1651483-3-scgl@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 7tDR0KUycFjp4Lsv5RKwE2wnjBxDMT9- X-Proofpoint-GUID: 1nw549AwDKrsGnOpDkSRKxOkHLr1kz5E 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-01-19_10,2022-01-19_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 impostorscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 adultscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201190104 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 18.01.22 um 10:52 schrieb Janis Schoetterl-Glausch: > Storage key checking had not been implemented for instructions emulated > by KVM. Implement it by enhancing the functions used for guest access, > in particular those making use of access_guest which has been renamed > to access_guest_with_key. > Accesses via access_guest_real should not be key checked. > > For actual accesses, key checking is done by __copy_from/to_user_with_key > (which internally uses MVCOS/MVCP/MVCS). > In cases where accessibility is checked without an actual access, > this is performed by getting the storage key and checking > if the access key matches. > In both cases, if applicable, storage and fetch protection override > are honored. > > Signed-off-by: Janis Schoetterl-Glausch > --- > arch/s390/include/asm/ctl_reg.h | 2 + > arch/s390/include/asm/page.h | 2 + > arch/s390/kvm/gaccess.c | 174 +++++++++++++++++++++++++++++--- > arch/s390/kvm/gaccess.h | 78 ++++++++++++-- > arch/s390/kvm/intercept.c | 12 +-- > arch/s390/kvm/kvm-s390.c | 4 +- > 6 files changed, 241 insertions(+), 31 deletions(-) > > diff --git a/arch/s390/include/asm/ctl_reg.h b/arch/s390/include/asm/ctl_reg.h > index 04dc65f8901d..c800199a376b 100644 > --- a/arch/s390/include/asm/ctl_reg.h > +++ b/arch/s390/include/asm/ctl_reg.h > @@ -12,6 +12,8 @@ > > #define CR0_CLOCK_COMPARATOR_SIGN BIT(63 - 10) > #define CR0_LOW_ADDRESS_PROTECTION BIT(63 - 35) > +#define CR0_FETCH_PROTECTION_OVERRIDE BIT(63 - 38) > +#define CR0_STORAGE_PROTECTION_OVERRIDE BIT(63 - 39) > #define CR0_EMERGENCY_SIGNAL_SUBMASK BIT(63 - 49) > #define CR0_EXTERNAL_CALL_SUBMASK BIT(63 - 50) > #define CR0_CLOCK_COMPARATOR_SUBMASK BIT(63 - 52) > diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h > index d98d17a36c7b..cfc4d6fb2385 100644 > --- a/arch/s390/include/asm/page.h > +++ b/arch/s390/include/asm/page.h > @@ -20,6 +20,8 @@ > #define PAGE_SIZE _PAGE_SIZE > #define PAGE_MASK _PAGE_MASK > #define PAGE_DEFAULT_ACC 0 > +/* storage-protection override */ > +#define PAGE_SPO_ACC 9 > #define PAGE_DEFAULT_KEY (PAGE_DEFAULT_ACC << 4) > > #define HPAGE_SHIFT 20 > diff --git a/arch/s390/kvm/gaccess.c b/arch/s390/kvm/gaccess.c > index 4460808c3b9a..92ab96d55504 100644 > --- a/arch/s390/kvm/gaccess.c > +++ b/arch/s390/kvm/gaccess.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > #include > #include "kvm-s390.h" > @@ -794,6 +795,79 @@ static int low_address_protection_enabled(struct kvm_vcpu *vcpu, > return 1; > } > > +static bool fetch_prot_override_applicable(struct kvm_vcpu *vcpu, enum gacc_mode mode, > + union asce asce) > +{ > + psw_t *psw = &vcpu->arch.sie_block->gpsw; > + unsigned long override; > + > + if (mode == GACC_FETCH || mode == GACC_IFETCH) { > + /* check if fetch protection override enabled */ > + override = vcpu->arch.sie_block->gcr[0]; > + override &= CR0_FETCH_PROTECTION_OVERRIDE; > + /* not applicable if subject to DAT && private space */ > + override = override && !(psw_bits(*psw).dat && asce.p); > + return override; > + } > + return false; > +} > + > +static bool fetch_prot_override_applies(unsigned long ga, unsigned int len) > +{ > + return ga < 2048 && ga + len <= 2048; > +} > + > +static bool storage_prot_override_applicable(struct kvm_vcpu *vcpu) > +{ > + /* check if storage protection override enabled */ > + return vcpu->arch.sie_block->gcr[0] & CR0_STORAGE_PROTECTION_OVERRIDE; > +} > + > +static bool storage_prot_override_applies(char access_control) > +{ > + /* matches special storage protection override key (9) -> allow */ > + return access_control == PAGE_SPO_ACC; > +} > + > +static int vcpu_check_access_key(struct kvm_vcpu *vcpu, char access_key, > + enum gacc_mode mode, union asce asce, gpa_t gpa, > + unsigned long ga, unsigned int len) > +{ > + unsigned char storage_key, access_control; > + unsigned long hva; > + int r; > + > + /* access key 0 matches any storage key -> allow */ > + if (access_key == 0) > + return 0; > + /* > + * caller needs to ensure that gfn is accessible, so we can > + * assume that this cannot fail > + */ > + hva = gfn_to_hva(vcpu->kvm, gpa_to_gfn(gpa)); > + mmap_read_lock(current->mm); > + r = get_guest_storage_key(current->mm, hva, &storage_key); > + mmap_read_unlock(current->mm); > + if (r) > + return r; > + access_control = FIELD_GET(_PAGE_ACC_BITS, storage_key); > + /* access key matches storage key -> allow */ > + if (access_control == access_key) > + return 0; > + if (mode == GACC_FETCH || mode == GACC_IFETCH) { > + /* mismatching keys, no fetch protection -> allowed */ > + if (!(storage_key & _PAGE_FP_BIT)) > + return 0; > + if (fetch_prot_override_applicable(vcpu, mode, asce)) > + if (fetch_prot_override_applies(ga, len)) > + return 0; > + } > + if (storage_prot_override_applicable(vcpu)) > + if (storage_prot_override_applies(access_control)) > + return 0; > + return PGM_PROTECTION; > +} This function is just a pre-check (and early-exit) and we do an additional final check in the MVCOS routing later on, correct? It might actually be faster to get rid of this pre-test and simply rely on MVCOS. MVCOS is usually just some cycles while ISKE to read the key is really slow path and take hundreds of cycles. This would even simplify the patch (assuming that we do proper key checking all the time).