Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3423117ybd; Tue, 25 Jun 2019 02:15:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqz0iSVXPztJgq6qPvwd5TCAcJOAlGsfckxbrEALvQ1Zn9ql6AXBbti8XYpOFYEnKjRjloBC X-Received: by 2002:a63:374a:: with SMTP id g10mr37113696pgn.31.1561454158044; Tue, 25 Jun 2019 02:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561454158; cv=none; d=google.com; s=arc-20160816; b=FQQKjcmkMYZvr6juG43t0rxtQqytr1JbK3vOz0dhhkLAd3YG4iK8EMcYjv8ZrBZ+XF 9c/1vXpWsjzCIZnbZe4BJLxWkbP6hBSAn2a2Xvyjg5cPmRUQ5Nyz/vO/pbapsNr7rHLc vHjgzX06OOK5FdLm6/0JbE04Z0hp1arI9EkClkhPJNa3M8BDeLIV0Q5mJYOH7RhkOZ1d dvYuf+vBevfItFpgqwkTZreADNpS9l5WIsgFzp9X+EDhQ+zvo8UHAD9u7Vyb9M3rhF+v aCZdP09YDZuryNtCsxVJH24QN/iWRV9V6b+xVJmVmoHN3e+x/x0ykSdADzDXjKN4z9l/ tf0Q== 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=ZcxdNwTy+w8bIfRO0CmpttCkIU/hNPjR9n+jkzDdjFo=; b=YCGnBYsxQFzsnjfDiXo2FLby0qggoudTIdNVJO71Cq7PhZ/a4T4wKZqFU+NS8MV/iL kw+H+h2WTLeusrYN1IOLaP3jEGkDxiP7hUK1zqVIh6CtbNYpmP4mRyLvvpFItppb14+j cFsyao5iVwYmsLMWxfeHr6XaeT3LFt5rltz7mYn3gVg/F/oRLJJMPNmF/1d+9eRzk5MD yWp5MRBACMbM04NDQiu3vgODal4N6a5K4mYNjmw1tuioVEbXYx+nd0Dm9qNu3kPr8Ywh HKlax+nmtWanN9zeT/65MyEIi4DTTdIWW08Kk5E9TmXEx9SjRnM5GOJu63FLh2Q/8NXy 7MoA== 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 21si13704306pfo.138.2019.06.25.02.15.42; Tue, 25 Jun 2019 02:15:58 -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 S1731225AbfFYJPV (ORCPT + 99 others); Tue, 25 Jun 2019 05:15:21 -0400 Received: from foss.arm.com ([217.140.110.172]:36364 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728365AbfFYJPU (ORCPT ); Tue, 25 Jun 2019 05:15:20 -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 AF806360; Tue, 25 Jun 2019 02:15:19 -0700 (PDT) Received: from fuggles.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 86CCB3F71E; Tue, 25 Jun 2019 02:15:16 -0700 (PDT) Date: Tue, 25 Jun 2019 10:15:07 +0100 From: Will Deacon To: Mathieu Desnoyers Cc: shuah , linux-kernel , Peter Zijlstra , Thomas Gleixner , Joel Fernandes , Catalin Marinas , Dave Watson , Andi Kleen , linux-kselftest , "H. Peter Anvin" , Chris Lameter , Russell King , Michael Kerrisk , "Paul E . McKenney" , Paul Turner , Boqun Feng , Josh Triplett , rostedt , Ben Maurer , linux-api , Andy Lutomirski , Andrew Morton , Linus Torvalds , carlos , Florian Weimer Subject: Re: [RFC PATCH 1/1] Revert "rseq/selftests: arm: use udf instruction for RSEQ_SIG" Message-ID: <20190625091507.GA13263@fuggles.cambridge.arm.com> References: <20190617152304.23371-1-mathieu.desnoyers@efficios.com> <20190624172429.GA11133@fuggles.cambridge.arm.com> <1620037196.377.1561400426591.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1620037196.377.1561400426591.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 24, 2019 at 02:20:26PM -0400, Mathieu Desnoyers wrote: > ----- On Jun 24, 2019, at 1:24 PM, Will Deacon will.deacon@arm.com wrote: > > > On Mon, Jun 17, 2019 at 05:23:04PM +0200, Mathieu Desnoyers wrote: > >> This reverts commit 2b845d4b4acd9422bbb668989db8dc36dfc8f438. > >> > >> That commit introduces build issues for programs compiled in Thumb mode. > >> Rather than try to be clever and emit a valid trap instruction on arm32, > >> which requires special care about big/little endian handling on that > >> architecture, just emit plain data. Data in the instruction stream is > >> technically expected on arm32: this is how literal pools are > >> implemented. Reverting to the prior behavior does exactly that. > >> > >> Signed-off-by: Mathieu Desnoyers > >> CC: Peter Zijlstra > >> CC: Thomas Gleixner > >> CC: Joel Fernandes > >> CC: Catalin Marinas > >> CC: Dave Watson > >> CC: Will Deacon > >> CC: Shuah Khan > >> CC: Andi Kleen > >> CC: linux-kselftest@vger.kernel.org > >> CC: "H . Peter Anvin" > >> CC: Chris Lameter > >> CC: Russell King > >> CC: Michael Kerrisk > >> CC: "Paul E . McKenney" > >> CC: Paul Turner > >> CC: Boqun Feng > >> CC: Josh Triplett > >> CC: Steven Rostedt > >> CC: Ben Maurer > >> CC: linux-api@vger.kernel.org > >> CC: Andy Lutomirski > >> CC: Andrew Morton > >> CC: Linus Torvalds > >> CC: Carlos O'Donell > >> CC: Florian Weimer > >> --- > >> tools/testing/selftests/rseq/rseq-arm.h | 52 ++------------------------------- > >> 1 file changed, 2 insertions(+), 50 deletions(-) > >> > >> diff --git a/tools/testing/selftests/rseq/rseq-arm.h > >> b/tools/testing/selftests/rseq/rseq-arm.h > >> index 84f28f147fb6..5f262c54364f 100644 > >> --- a/tools/testing/selftests/rseq/rseq-arm.h > >> +++ b/tools/testing/selftests/rseq/rseq-arm.h > >> @@ -5,54 +5,7 @@ > >> * (C) Copyright 2016-2018 - Mathieu Desnoyers > >> */ > >> > >> -/* > >> - * RSEQ_SIG uses the udf A32 instruction with an uncommon immediate operand > >> - * value 0x5de3. This traps if user-space reaches this instruction by mistake, > >> - * and the uncommon operand ensures the kernel does not move the instruction > >> - * pointer to attacker-controlled code on rseq abort. > >> - * > >> - * The instruction pattern in the A32 instruction set is: > >> - * > >> - * e7f5def3 udf #24035 ; 0x5de3 > >> - * > >> - * This translates to the following instruction pattern in the T16 instruction > >> - * set: > >> - * > >> - * little endian: > >> - * def3 udf #243 ; 0xf3 > >> - * e7f5 b.n <7f5> > >> - * > >> - * pre-ARMv6 big endian code: > >> - * e7f5 b.n <7f5> > >> - * def3 udf #243 ; 0xf3 > >> - * > >> - * ARMv6+ -mbig-endian generates mixed endianness code vs data: little-endian > >> - * code and big-endian data. Ensure the RSEQ_SIG data signature matches code > >> - * endianness. Prior to ARMv6, -mbig-endian generates big-endian code and data > >> - * (which match), so there is no need to reverse the endianness of the data > >> - * representation of the signature. However, the choice between BE32 and BE8 > >> - * is done by the linker, so we cannot know whether code and data endianness > >> - * will be mixed before the linker is invoked. > >> - */ > >> - > >> -#define RSEQ_SIG_CODE 0xe7f5def3 > >> - > >> -#ifndef __ASSEMBLER__ > >> - > >> -#define RSEQ_SIG_DATA \ > >> - ({ \ > >> - int sig; \ > >> - asm volatile ("b 2f\n\t" \ > >> - "1: .inst " __rseq_str(RSEQ_SIG_CODE) "\n\t" \ > >> - "2:\n\t" \ > >> - "ldr %[sig], 1b\n\t" \ > >> - : [sig] "=r" (sig)); \ > >> - sig; \ > >> - }) > >> - > >> -#define RSEQ_SIG RSEQ_SIG_DATA > >> - > >> -#endif > >> +#define RSEQ_SIG 0x53053053 > > > > I don't get why you're reverting back to this old signature value, when the > > one we came up with will work well when interpreted as an instruction in the > > *vast* majority of scenarios that people care about (A32/T32 little-endian). > > I think you might be under-estimating just how dead things like BE32 really > > are. > > My issue is that the current .instr approach is broken for programs or functions > built in Thumb mode, and I received no feedback on the solutions I proposed for > those issues, which led me to propose a patch reverting to a simple .word. I understand why you're moving from .inst to .word, but I don't understand why that necessitates a change in the value. Why not .word 0xe7f5def3 ? You could also flip the bytes around in case of big-endian, which would keep the instruction coding clean for BE8. > > That said, when you ran into .inst.n/.inst.w issues, did you try something > > along the lines of the WASM() macro we use in arch/arm/, which adds the ".w" > > suffix when targetting Thumb? > > AFAIU, the WASM macros depend on CONFIG_THUMB2_KERNEL, which may be fine within > the kernel, but for user-space things are a bit more complex. > > A compile-unit can be compiled as thumb, which will set a compiler define > which we could use to detect thumb mode. However, unfortunately, a single > function can also be compiled with an attribute selecting thumb mode, which > AFAIU does not influence the preprocessor defines. Thanks, I hadn't considered that case. I don't know the right way to handle that in the toolchain, so using .word is probably the best bet in the absence of any better suggestions from the tools folks. Will