Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2836790ybd; Mon, 24 Jun 2019 13:40:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqyiRYsFWwfp5pAw/H68qG1AAkgsSK7C0hgsDWG+dU+Ppl1Ms/Js4N3pnvd0pQx4i+Dilzly X-Received: by 2002:a17:902:467:: with SMTP id 94mr93726947ple.131.1561408850767; Mon, 24 Jun 2019 13:40:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561408850; cv=none; d=google.com; s=arc-20160816; b=STL/hZ11EHqzwAgm+0T3QjOs5JtVp6QHDxOUejzbb7/dGSjQYsZH8EKKbIDVeCohFG 7SIbdJcjITYxgT4RJY5u7uRtSVJZyC/EeQ3e4jyT5NihXrfKx1zjAPQmAqgBFhltcIiD 7EBNyyhcmKjswmT7gQKI6fdV6ueSDoKi884Era5Ezr3l2SpnlhnE+wbjK5JjDC12Kxhs wpuLYGDrd/+Xb5t/NKWLoagSuUoAUAhv2LtiJQ6QMq8Z0V59vRYxNKx7YFFHv6vBuk5d u0xYnv4mC4dOFmwG+IBroquqmXRtDvVczXgXbqD4mnqaFmC6dfrmydrFlJcOqTzmERVa Pnxw== 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=R3oxdy+SZAHwG7iImlT9eViUCF8CYZkLjH9ESaUBUuE=; b=J/BNMaLNetDUXjqEaVmfx9JmGXXTFYSv9FUoiMjWfg2obGix377GZMqptuRydtWwic L+hNSjoIT2YL9AHoD1d8bC4YKzJUHDtmkxfWeBb7U2vLjfiZbD7lWzJtCSaE+oE9wucq 2YVnLPjsh6U48AUclq+824z/nBHD7zvO3hbAFlt/Exb+5ZD/ER/Pter52Kk+D3zlSVPS G6f0etHQH5CHVg/Td2L0cWYs2omHrmgA/GHMPApCutycSOvQny8xd79j+sQG584WoSiq KHOYZI8zDbZu2FLjbYG4gUJWz0KZ6hDaHwTXp4bZDefoN5GP/NdG+FOu/aE8R9NERTED +K7A== 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 y190si6445463pgd.449.2019.06.24.13.40.33; Mon, 24 Jun 2019 13:40:50 -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 S1732394AbfFXRYi (ORCPT + 99 others); Mon, 24 Jun 2019 13:24:38 -0400 Received: from foss.arm.com ([217.140.110.172]:55346 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726941AbfFXRYi (ORCPT ); Mon, 24 Jun 2019 13:24:38 -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 83073C0A; Mon, 24 Jun 2019 10:24:37 -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 63FA93F718; Mon, 24 Jun 2019 10:24:34 -0700 (PDT) Date: Mon, 24 Jun 2019 18:24:29 +0100 From: Will Deacon To: Mathieu Desnoyers Cc: Shuah Khan , linux-kernel@vger.kernel.org, Peter Zijlstra , Thomas Gleixner , Joel Fernandes , Catalin Marinas , Dave Watson , Andi Kleen , linux-kselftest@vger.kernel.org, "H . Peter Anvin" , Chris Lameter , Russell King , Michael Kerrisk , "Paul E . McKenney" , Paul Turner , Boqun Feng , Josh Triplett , Steven Rostedt , Ben Maurer , linux-api@vger.kernel.org, Andy Lutomirski , Andrew Morton , Linus Torvalds , Carlos O'Donell , Florian Weimer Subject: Re: [RFC PATCH 1/1] Revert "rseq/selftests: arm: use udf instruction for RSEQ_SIG" Message-ID: <20190624172429.GA11133@fuggles.cambridge.arm.com> References: <20190617152304.23371-1-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190617152304.23371-1-mathieu.desnoyers@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 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. 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? Will