Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp984298ybp; Fri, 11 Oct 2019 07:23:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzerS6oU6sRcl9fOSHp2N+hxNEXXk9eC3IfUa4oX7fd9k5YNXoEj7NPqCGdrWV9LroLA+R3 X-Received: by 2002:aa7:cd43:: with SMTP id v3mr13499395edw.235.1570803809092; Fri, 11 Oct 2019 07:23:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570803809; cv=none; d=google.com; s=arc-20160816; b=fD/XFDjCwqpmrT71wTVToCuBkvFsQ9/KzvdYFDIgtsjING6xixgDb3xEFeaGXMKjsH sPIvq52DidTdaeddYbRnO2aLdCZo1JjhB7f2T3p+j4XX1JTy8Yn4fu87Rc82pkTFx/PQ ojXceyia3utCu4Pvcnz4zMgCXsmpE9ASj66npek30Y0UD9WRy9Bb3bllIpv3hnOjYE2p SvQljr/oiul9Nyt+RHGBSWxJ+TgIgnzp8JP9r33gY5/DslSgTY16d7+Kvr43qWNFkEFE xFi7worDS9v2P1eXKqBqkROHi7eKUAZz6Yu9I4eCBm4fh/5VmnuJYGfndHFzvtOlIYm9 kQCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9xQ3u2fRY/7IZSuC4ZKj9aFAO/dRRWk/J2X3pGKs1Ok=; b=S4LESMieXlQW7TIV4Ybv61nlxRQOdoQSQaU8FJkhJL6cs7iTcEx4e53Kc+OUWbsRUi y40M+whhWiCwy0PwWVNdd5x0T0Cot2Tb1XwOuMIYD2uAFBUsLchpz4nHhJWwgaOr6oOt vMf2tBWecEIQPs46igd1c2qZ885ae4aFhtPcvtUTdCv9gKuf+cePpjYWih0l46dV1iFT VBs8kKwybUbu/856p5y4tiwbYtn7IT9d5UeMRTn6C14RDb/DwztwTqxW0HAeTckB63oH XZ+5A6eXNnhqmWJlLkZ7hRerjl/r6c5DnJ8X0yS31msR9ZEcU0fvmGCJ02osXoekMamU ON4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oe23si5215531ejb.199.2019.10.11.07.23.05; Fri, 11 Oct 2019 07:23:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728543AbfJKOWE (ORCPT + 99 others); Fri, 11 Oct 2019 10:22:04 -0400 Received: from foss.arm.com ([217.140.110.172]:33928 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728068AbfJKOWE (ORCPT ); Fri, 11 Oct 2019 10:22:04 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3816F142F; Fri, 11 Oct 2019 07:22:03 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 51D463F68E; Fri, 11 Oct 2019 07:22:00 -0700 (PDT) Date: Fri, 11 Oct 2019 15:21:58 +0100 From: Mark Rutland To: Dave Martin Cc: linux-kernel@vger.kernel.org, Andrew Jones , Arnd Bergmann , Catalin Marinas , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Kees Cook , Kristina =?utf-8?Q?Mart=C5=A1enko?= , Mark Brown , Paul Elliott , Peter Zijlstra , Richard Henderson , Sudakshina Das , Szabolcs Nagy , Thomas Gleixner , Will Deacon , Yu-cheng Yu , Amit Kachhap , Vincenzo Frascino , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 11/12] arm64: BTI: Reset BTYPE when skipping emulated instructions Message-ID: <20191011142157.GC33537@lakrids.cambridge.arm.com> References: <1570733080-21015-1-git-send-email-Dave.Martin@arm.com> <1570733080-21015-12-git-send-email-Dave.Martin@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1570733080-21015-12-git-send-email-Dave.Martin@arm.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 10, 2019 at 07:44:39PM +0100, Dave Martin wrote: > Since normal execution of any non-branch instruction resets the > PSTATE BTYPE field to 0, so do the same thing when emulating a > trapped instruction. > > Branches don't trap directly, so we should never need to assign a > non-zero value to BTYPE here. > > Signed-off-by: Dave Martin > --- > arch/arm64/kernel/traps.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index 3af2768..4d8ce50 100644 > --- a/arch/arm64/kernel/traps.c > +++ b/arch/arm64/kernel/traps.c > @@ -331,6 +331,8 @@ void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size) > > if (regs->pstate & PSR_MODE32_BIT) > advance_itstate(regs); > + else > + regs->pstate &= ~(u64)PSR_BTYPE_MASK; This looks good to me, with one nit below. We don't (currently) need the u64 cast here, and it's inconsistent with what we do elsewhere. If the upper 32-bit of pstate get allocated, we'll need to fix up all the other masking we do: [mark@lakrids:~/src/linux]% git grep 'pstate &= ~' arch/arm64/kernel/armv8_deprecated.c: regs->pstate &= ~PSR_AA32_E_BIT; arch/arm64/kernel/cpufeature.c: regs->pstate &= ~PSR_SSBS_BIT; arch/arm64/kernel/debug-monitors.c: regs->pstate &= ~DBG_SPSR_SS; arch/arm64/kernel/insn.c: pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */ arch/arm64/kernel/insn.c: pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */ arch/arm64/kernel/probes/kprobes.c: regs->pstate &= ~PSR_D_BIT; arch/arm64/kernel/probes/kprobes.c: regs->pstate &= ~DAIF_MASK; arch/arm64/kernel/ptrace.c: regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS; arch/arm64/kernel/ptrace.c: regs->pstate &= ~PSR_AA32_E_BIT; arch/arm64/kernel/ptrace.c: regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS; arch/arm64/kernel/ptrace.c: regs->pstate &= ~DBG_SPSR_SS; arch/arm64/kernel/ssbd.c: task_pt_regs(task)->pstate &= ~val; arch/arm64/kernel/traps.c: regs->pstate &= ~PSR_AA32_IT_MASK; ... and at that point I'd suggest we should just ensure the bit definitions are all defined as unsigned long in the first place since adding casts to each use is error-prone. Thanks, Mark.