From nobody Mon Apr 29 12:08:40 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1566479815; cv=none; d=zoho.com; s=zohoarc; b=NyJ0AyX0k+qzLvJ/75Nu7rqny5B0Z9/VuPUj5eVdNARWsu2nRFQYEqAbrQvSqHjYDSiAFgB6fsn2b7/wLUa8yJ4ep1M7Xf+EY8bBTVcx9tlTQs8BndHsmOEDjRLPn6VRUYhZuNQWoVxjWMDhoI2yg1XgyKYSVgri0wKjqQ17XS8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1566479815; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=V2nv/Uxsp/eRjcm2yZv9NXMn6rt7OMPnJeNLZd1Dp3Y=; b=Gd7qftd/j5rwXQTLlDzwwiqVCdJtq4RZKOErfDjhgk5Td+zYE87pM5ORN3FZHyHlBxYkdoBwFo729MYjIxgl+8H7VKAy4fwOZqbX2JH1XKSEz4sCAM23XvyvlVJPYQ2U2I6h2BJMWMG5G1dmzefkVVk+1V3zwwIrBQeizaKS3hQ= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1566479815375966.8942119985367; Thu, 22 Aug 2019 06:16:55 -0700 (PDT) Received: from localhost ([::1]:42892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i0mxH-0005ce-Nv for importer@patchew.org; Thu, 22 Aug 2019 09:16:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34964) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i0mwH-00052d-1K for qemu-devel@nongnu.org; Thu, 22 Aug 2019 09:15:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i0mwF-0007im-45 for qemu-devel@nongnu.org; Thu, 22 Aug 2019 09:15:40 -0400 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:38941) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i0mwE-0007hy-SY for qemu-devel@nongnu.org; Thu, 22 Aug 2019 09:15:39 -0400 Received: by mail-wm1-x344.google.com with SMTP id i63so5742677wmg.4 for ; Thu, 22 Aug 2019 06:15:37 -0700 (PDT) Received: from orth.archaic.org.uk (orth.archaic.org.uk. [81.2.115.148]) by smtp.gmail.com with ESMTPSA id p13sm30785512wrw.90.2019.08.22.06.15.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 06:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=V2nv/Uxsp/eRjcm2yZv9NXMn6rt7OMPnJeNLZd1Dp3Y=; b=Obskk4O93IojLMpFd7xriHxXntHqP0lpIV2N020nuuSVcptX8Va7IbYfuCoFEX01KW FZBDK+9X/F0O4sglPOLQhSEpH9yzKpBJR0gUCXO8+2gu/ZrTKTCZgXbxAFtDZl70b7ek UUpNPobf4Mkd3b8oMTG423OeFlx/y/wMJbQzieYoHyt2P2EuSt9OQw8wdBsh/JgOsUYR rhXGE92CRbfePHfKV71KmcCkcL6Kkmlf9vH9Z/ikqpYqkaE61Bh/0KcUHAajQBCCTT6h 6neTkMiP9JG0AN7aVmXQACwa5eHm90v3995zfTvs3gEZv3EV5Li8j6xCARXwUTF1ZlRP oH1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=V2nv/Uxsp/eRjcm2yZv9NXMn6rt7OMPnJeNLZd1Dp3Y=; b=WhTU9i1lk6qKpNySgTKIb7I9DCfQrH2xBgzb3AMcbGWR+4Rpcm7Nmf8/CIB3kFvO93 E3H68LWWHIw19xLQ1rUZybfa03xNwy6orZJTze8hKdkHxBYQE+ZaM++anoqOd8g7MjAR 5lYBg6jDOzelWcW2NCBcSn0hxjBzYh+cFQ5vf3OhT/M91OYmLbeAXtHJJPvLBFVPtHF0 zhKJDC46qI/6jJyuo9mQgM7DfFERkcFgrB4CXea4+Et7pidlipmeWjOm/WilillNM/tU AqP2eHOTABSzKC01YzgNWxwS02Yk4dfvjBHsD3ozMsBFjkflINLo0odlnJER9e+4QnUn sSqA== X-Gm-Message-State: APjAAAWDivsG7uCSTsEF10sLTPmxqy66RXaj2votmZKVukiBawhCezic HCZcGLBAm5yRpDvHWNyNESGp0w== X-Google-Smtp-Source: APXvYqxtxXa2t+mTXFy1Nb9LhGYR+NfblypRwAn+B8V/YsP4MNqa9sV190xRju24CwwoJk+WC4gIkA== X-Received: by 2002:a1c:ca09:: with SMTP id a9mr6189818wmg.43.1566479736729; Thu, 22 Aug 2019 06:15:36 -0700 (PDT) From: Peter Maydell To: qemu-arm@nongnu.org, qemu-devel@nongnu.org Date: Thu, 22 Aug 2019 14:15:34 +0100 Message-Id: <20190822131534.16602-1-peter.maydell@linaro.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::344 Subject: [Qemu-devel] [PATCH] target/arm: Don't abort on M-profile exception return in linux-user mode 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: Christophe Lyon , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" 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 Fixes: https://bugs.launchpad.net/qemu/+bug/1840922 Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson --- I have no idea how we could achieve the "restrict addresses shown to guest for linux-user" mentioned in the last para: any suggestions? --- target/arm/translate.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/target/arm/translate.c b/target/arm/translate.c index cbe19b7a625..98e7105ecd2 100644 --- a/target/arm/translate.c +++ b/target/arm/translate.c @@ -915,10 +915,27 @@ static inline void gen_bx(DisasContext *s, TCGv_i32 v= ar) store_cpu_field(var, thumb); } =20 -/* 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 t= o 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) { @@ -926,10 +943,12 @@ static inline void gen_bx_excret(DisasContext *s, TCG= v_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 =3D DISAS_BX_EXCRET; } +#endif } =20 static inline void gen_bx_excret_final_code(DisasContext *s) --=20 2.20.1