Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2823507pxv; Mon, 12 Jul 2021 02:49:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbrhc/7Tgty+TxAr2H34+JWWAwhwRTBqQFpy9LyRXe/rRrLHlmQlUtJuKYfvSdd3lpItzK X-Received: by 2002:a92:a013:: with SMTP id e19mr16813359ili.206.1626083369123; Mon, 12 Jul 2021 02:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626083369; cv=none; d=google.com; s=arc-20160816; b=uJ9/lGkOxpQIsWBCtSVf7CMGaFhFcjJysdYRKIvAVS/P//vMGW4vNiYsplujF3xpUD b3cnnGUYbO8Qtm4YfvMAF+cJDwHWHQvUWcvE0d5lIHiTdkUkCzC8bme20XLTRkxAAbEI 20ixLT83jXaiATJrekYILZYoc3m4Rl9D/Oq/zkoNvKrLqqDJmZR123U7KdqM949E1yD9 UjNOiWYfEbODKSAQ0uJGg65G0DZkXWFy3pnDijZo2xjSZ2WGeY5Un9ro2EmbpbxgLZpy 8KLxW1oE1i702ReXkW/CXjD+6w/UmCiE+JEx/zUYUZg5ZVg00gI7Lg3QXAgp5m/ZxzJF 7dEA== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=xCfL+Pkq2iHY07owEOHCKkUR4Z/74+LDbzfZo+/Z1RA=; b=Tf9yiRKNsl+3mEYlXmdszUTnmZT9TkqR/RQ2WLQksN+LVXjGBScSWykG0odF6EJUJs q+Y83fcfMFGlixZWtIDRJIgm24VuE/r+UjYv9msXTKw/VSgdfJ8v/ZYDHZkQbsPBMsGy /esAO9zomSBdJEScQIHAvKMmHrznvzzB3b0F7+xarGbCdrE4xIPDS7Cbn1CnbkPfZNQk MUXE7kn9BI9MZmIU5kNkBrRrZUGioOF8mPoqX1ywFWWkW3/bGA2ZsruTZrGjyD5w7Dxo 9axP5MTnQ47TUNeWPMkHAZE0j8c2kAGO6FPeEmkVwmEHiIgBPYm3qdSgszUd7FMJiKAq rHVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=mG1XH5pM; 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=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k11si18279063jav.18.2021.07.12.02.49.17; Mon, 12 Jul 2021 02:49:29 -0700 (PDT) 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=@linuxfoundation.org header.s=korg header.b=mG1XH5pM; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235415AbhGLGpN (ORCPT + 99 others); Mon, 12 Jul 2021 02:45:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:53518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237899AbhGLGe5 (ORCPT ); Mon, 12 Jul 2021 02:34:57 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0A8EC60551; Mon, 12 Jul 2021 06:32:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626071529; bh=wWJRJTiR/yYrM97bNtwEoMlpAdV7hfKPseOeLbgd8po=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mG1XH5pMQWQa+pouSHEaEaD1UGdBszkS2GtEX6ctOYDTZh3T5QAiy9seYkHFlqFU5 +ZOrD/cyLF9ZNxknkGZ6v5Ww9KzV9f4sSab40OY2mPYum3Is/pigYYZobb/1+fhGox bxY1yXvDTiG3ShPDrW2OywLkAZlLv0VXSWKqAQjA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Janosch Frank , Christian Borntraeger , Vasily Gorbik Subject: [PATCH 5.10 066/593] s390: mm: Fix secure storage access exception handling Date: Mon, 12 Jul 2021 08:03:46 +0200 Message-Id: <20210712060850.429885157@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060843.180606720@linuxfoundation.org> References: <20210712060843.180606720@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Janosch Frank commit 85b18d7b5e7ffefb2f076186511d39c4990aa005 upstream. Turns out that the bit 61 in the TEID is not always 1 and if that's the case the address space ID and the address are unpredictable. Without an address and its address space ID we can't export memory and hence we can only send a SIGSEGV to the process or panic the kernel depending on who caused the exception. Unfortunately bit 61 is only reliable if we have the "misc" UV feature bit. Signed-off-by: Janosch Frank Reviewed-by: Christian Borntraeger Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers") Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman --- arch/s390/boot/uv.c | 1 + arch/s390/include/asm/uv.h | 8 +++++++- arch/s390/kernel/uv.c | 10 ++++++++++ arch/s390/mm/fault.c | 26 ++++++++++++++++++++++++++ 4 files changed, 44 insertions(+), 1 deletion(-) --- a/arch/s390/boot/uv.c +++ b/arch/s390/boot/uv.c @@ -36,6 +36,7 @@ void uv_query_info(void) uv_info.max_sec_stor_addr = ALIGN(uvcb.max_guest_stor_addr, PAGE_SIZE); uv_info.max_num_sec_conf = uvcb.max_num_sec_conf; uv_info.max_guest_cpu_id = uvcb.max_guest_cpu_id; + uv_info.uv_feature_indications = uvcb.uv_feature_indications; } #ifdef CONFIG_PROTECTED_VIRTUALIZATION_GUEST --- a/arch/s390/include/asm/uv.h +++ b/arch/s390/include/asm/uv.h @@ -73,6 +73,10 @@ enum uv_cmds_inst { BIT_UVC_CMD_UNPIN_PAGE_SHARED = 22, }; +enum uv_feat_ind { + BIT_UV_FEAT_MISC = 0, +}; + struct uv_cb_header { u16 len; u16 cmd; /* Command Code */ @@ -97,7 +101,8 @@ struct uv_cb_qui { u64 max_guest_stor_addr; u8 reserved88[158 - 136]; u16 max_guest_cpu_id; - u8 reserveda0[200 - 160]; + u64 uv_feature_indications; + u8 reserveda0[200 - 168]; } __packed __aligned(8); /* Initialize Ultravisor */ @@ -274,6 +279,7 @@ struct uv_info { unsigned long max_sec_stor_addr; unsigned int max_num_sec_conf; unsigned short max_guest_cpu_id; + unsigned long uv_feature_indications; }; extern struct uv_info uv_info; --- a/arch/s390/kernel/uv.c +++ b/arch/s390/kernel/uv.c @@ -364,6 +364,15 @@ static ssize_t uv_query_facilities(struc static struct kobj_attribute uv_query_facilities_attr = __ATTR(facilities, 0444, uv_query_facilities, NULL); +static ssize_t uv_query_feature_indications(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return sysfs_emit(buf, "%lx\n", uv_info.uv_feature_indications); +} + +static struct kobj_attribute uv_query_feature_indications_attr = + __ATTR(feature_indications, 0444, uv_query_feature_indications, NULL); + static ssize_t uv_query_max_guest_cpus(struct kobject *kobj, struct kobj_attribute *attr, char *page) { @@ -396,6 +405,7 @@ static struct kobj_attribute uv_query_ma static struct attribute *uv_query_attrs[] = { &uv_query_facilities_attr.attr, + &uv_query_feature_indications_attr.attr, &uv_query_max_guest_cpus_attr.attr, &uv_query_max_guest_vms_attr.attr, &uv_query_max_guest_addr_attr.attr, --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -805,6 +805,32 @@ void do_secure_storage_access(struct pt_ struct page *page; int rc; + /* + * bit 61 tells us if the address is valid, if it's not we + * have a major problem and should stop the kernel or send a + * SIGSEGV to the process. Unfortunately bit 61 is not + * reliable without the misc UV feature so we need to check + * for that as well. + */ + if (test_bit_inv(BIT_UV_FEAT_MISC, &uv_info.uv_feature_indications) && + !test_bit_inv(61, ®s->int_parm_long)) { + /* + * When this happens, userspace did something that it + * was not supposed to do, e.g. branching into secure + * memory. Trigger a segmentation fault. + */ + if (user_mode(regs)) { + send_sig(SIGSEGV, current, 0); + return; + } + + /* + * The kernel should never run into this case and we + * have no way out of this situation. + */ + panic("Unexpected PGM 0x3d with TEID bit 61=0"); + } + switch (get_fault_type(regs)) { case USER_FAULT: mm = current->mm;