From patchwork Tue Oct 1 23:45:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Roth X-Patchwork-Id: 174947 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp107009ill; Tue, 1 Oct 2019 18:28:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqxvhP1z5abYh7mJYnb9hGWcs0eidiB1J7hzbMj+PWdJEm2glKBSka+9/5abvOy0wKFPEW0c X-Received: by 2002:ae9:eb51:: with SMTP id b78mr1320569qkg.452.1569979713962; Tue, 01 Oct 2019 18:28:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569979713; cv=none; d=google.com; s=arc-20160816; b=meAGVRjCwTUXmZzYa5pR+tjYxUIZ95y2Ftn+IAX8NUWtafNSYrKCpsedkHSxGLqRgO 6KEppkcNVBWRxzm46jziZfdrlO1Hs6f4buW26PnAT74gGPbOmDwLzms7j0tqwzs2t7IV 6jiDtdDnDa/N7llpb4yrU5nDT6qX/qUF/k3+5mPLb/0UiC7N+RGBBW89S8NSnTJNnIGT XVOkck0r6LX4KH362RrPB6/8t7TMrrUh8txbwmyif5uAQ3Q74Y0K57Fzi6KAAKpP16Jm UuDbivqmfatPNXTJABQCE1P0Kshf/DoxebkdxSDVdep/c7Ymv36YmC5eBa4GqzRYC47t w0HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:references:in-reply-to :message-id:date:subject:to:from; bh=dKTaeJ3AmYxRhHCmywjO26Wnln0EwXo8PT2H1XHjLKg=; b=VkjMsFR61fuCsC4ty1+BrodwN+YVo6PgMLw0zJ0Am25lzI+oSHCCgZc1Ia3iSQOwaF 2LHp2KmJ3wdkvxv4JGGe6r+8QL8VJevcFzsUkqUiqBVIiqvnyfoWOMgd5jRDbKkLgfkI tTX0al4ElYhVTAzXuAjJsPrXS3oIuZHWjtB38iIfcCKnroC0UsQogeMl6ViAlvT9Hn0l c9EgMYD1n+uz3RKJcFE3Lh1wjQGVp1X1LsgVAALWozEzKfNNWmptPcsOexopNjvHTFn3 7MQCjsnP2S7U1f1l9cwCF/qhEfbB1P4o7aKvgg0JHYGlJV6IanVRFnK0fkF+/wrPJi0i /RuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id d39si16256413qvc.55.2019.10.01.18.28.33 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 Oct 2019 18:28:33 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from localhost ([::1]:50182 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFTRR-0005Zj-6B for patch@linaro.org; Tue, 01 Oct 2019 21:28:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41339) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFRsq-0002GS-VN for qemu-devel@nongnu.org; Tue, 01 Oct 2019 19:48:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFRsi-0002wP-I5 for qemu-devel@nongnu.org; Tue, 01 Oct 2019 19:48:42 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:8688) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iFRsO-0001z8-GK; Tue, 01 Oct 2019 19:48:19 -0400 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x91NlSJr086592; Tue, 1 Oct 2019 19:47:54 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 2vccat810x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2019 19:47:53 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x91NjlZ2029380; Tue, 1 Oct 2019 23:47:52 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma01dal.us.ibm.com with ESMTP id 2v9y59fak2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2019 23:47:52 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x91NlqxN36831538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Oct 2019 23:47:52 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 12F442805E; Tue, 1 Oct 2019 23:47:52 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA8F728058; Tue, 1 Oct 2019 23:47:51 +0000 (GMT) Received: from localhost (unknown [9.53.179.213]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 1 Oct 2019 23:47:51 +0000 (GMT) From: Michael Roth To: qemu-devel@nongnu.org Subject: [PATCH 73/97] target/arm: Don't abort on M-profile exception return in linux-user mode Date: Tue, 1 Oct 2019 18:45:52 -0500 Message-Id: <20191001234616.7825-74-mdroth@linux.vnet.ibm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20191001234616.7825-1-mdroth@linux.vnet.ibm.com> References: <20191001234616.7825-1-mdroth@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010203 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.156.1 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , qemu-stable@nongnu.org Errors-To: qemu-devel-bounces+patch=linaro.org@nongnu.org Sender: "Qemu-devel" From: Peter Maydell An attempt to do an exception-return (branch to one of the magic addresses) in linux-user mode for M-profile should behave like a normal branch, because linux-user mode is always going to be in 'handler' mode. This used to work, but we broke it when we added support for the M-profile security extension in commit d02a8698d7ae2bfed. In that commit we allowed even handler-mode calls to magic return values to be checked for and dealt with by causing an EXCP_EXCEPTION_EXIT exception to be taken, because this is needed for the FNC_RETURN return-from-non-secure-function-call handling. For system mode we added a check in do_v7m_exception_exit() to make any spurious calls from Handler mode behave correctly, but forgot that linux-user mode would also be affected. How an attempted return-from-non-secure-function-call in linux-user mode should be handled is not clear -- on real hardware it would result in return to secure code (not to the Linux kernel) which could then handle the error in any way it chose. For QEMU we take the simple approach of treating this erroneous return the same way it would be handled on a CPU without the security extensions -- treat it as a normal branch. The upshot of all this is that for linux-user mode we should never do any of the bx_excret magic, so the code change is simple. This ought to be a weird corner case that only affects broken guest code (because Linux user processes should never be attempting to do exception returns or NS function returns), except that the code that assigns addresses in RAM for the process and stack in our linux-user code does not attempt to avoid this magic address range, so legitimate code attempting to return to a trampoline routine on the stack can fall into this case. This change fixes those programs, but we should also look at restricting the range of memory we use for M-profile linux-user guests to the area that would be real RAM in hardware. Cc: qemu-stable@nongnu.org Reported-by: Christophe Lyon Reviewed-by: Richard Henderson Signed-off-by: Peter Maydell Message-id: 20190822131534.16602-1-peter.maydell@linaro.org Fixes: https://bugs.launchpad.net/qemu/+bug/1840922 Signed-off-by: Peter Maydell (cherry picked from commit 5e5584c89f36b302c666bc6db535fd3f7ff35ad2) Signed-off-by: Michael Roth --- target/arm/translate.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) -- 2.17.1 diff --git a/target/arm/translate.c b/target/arm/translate.c index d408e4d7ef..d9d4e765ca 100644 --- a/target/arm/translate.c +++ b/target/arm/translate.c @@ -964,10 +964,27 @@ static inline void gen_bx(DisasContext *s, TCGv_i32 var) store_cpu_field(var, thumb); } -/* Set PC and Thumb state from var. var is marked as dead. +/* + * Set PC and Thumb state from var. var is marked as dead. * For M-profile CPUs, include logic to detect exception-return * branches and handle them. This is needed for Thumb POP/LDM to PC, LDR to PC, * and BX reg, and no others, and happens only for code in Handler mode. + * The Security Extension also requires us to check for the FNC_RETURN + * which signals a function return from non-secure state; this can happen + * in both Handler and Thread mode. + * To avoid having to do multiple comparisons in inline generated code, + * we make the check we do here loose, so it will match for EXC_RETURN + * in Thread mode. For system emulation do_v7m_exception_exit() checks + * for these spurious cases and returns without doing anything (giving + * the same behaviour as for a branch to a non-magic address). + * + * In linux-user mode it is unclear what the right behaviour for an + * attempted FNC_RETURN should be, because in real hardware this will go + * directly to Secure code (ie not the Linux kernel) which will then treat + * the error in any way it chooses. For QEMU we opt to make the FNC_RETURN + * attempt behave the way it would on a CPU without the security extension, + * which is to say "like a normal branch". That means we can simply treat + * all branches as normal with no magic address behaviour. */ static inline void gen_bx_excret(DisasContext *s, TCGv_i32 var) { @@ -975,10 +992,12 @@ static inline void gen_bx_excret(DisasContext *s, TCGv_i32 var) * s->base.is_jmp that we need to do the rest of the work later. */ gen_bx(s, var); +#ifndef CONFIG_USER_ONLY if (arm_dc_feature(s, ARM_FEATURE_M_SECURITY) || (s->v7m_handler_mode && arm_dc_feature(s, ARM_FEATURE_M))) { s->base.is_jmp = DISAS_BX_EXCRET; } +#endif } static inline void gen_bx_excret_final_code(DisasContext *s)