From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65452C10F11 for ; Wed, 24 Apr 2019 16:45:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40152206A3 for ; Wed, 24 Apr 2019 16:45:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732733AbfDXQpH (ORCPT ); Wed, 24 Apr 2019 12:45:07 -0400 Received: from foss.arm.com ([217.140.101.70]:48766 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726935AbfDXQpG (ORCPT ); Wed, 24 Apr 2019 12:45:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18F5D374; Wed, 24 Apr 2019 09:45:06 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C458B3F557; Wed, 24 Apr 2019 09:45:01 -0700 (PDT) Date: Wed, 24 Apr 2019 17:44:57 +0100 From: Will Deacon To: Mark Rutland Cc: Mathieu Desnoyers , Peter Zijlstra , "Paul E . McKenney" , Boqun Feng , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Thomas Gleixner , Andy Lutomirski , Dave Watson , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H . Peter Anvin" , Andi Kleen , Chris Lameter , Ben Maurer , Steven Rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Michael Kerrisk , Joel Fernandes , Shuah Khan , linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH for 5.2 08/10] rseq/selftests: aarch64 code signature: handle big-endian environment Message-ID: <20190424164457.GA18611@fuggles.cambridge.arm.com> References: <20190424152502.14246-1-mathieu.desnoyers@efficios.com> <20190424152502.14246-9-mathieu.desnoyers@efficios.com> <20190424164032.GD21101@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190424164032.GD21101@lakrids.cambridge.arm.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 Wed, Apr 24, 2019 at 05:40:33PM +0100, Mark Rutland wrote: > On Wed, Apr 24, 2019 at 11:25:00AM -0400, Mathieu Desnoyers wrote: > > Handle compiling with -mbig-endian on aarch64, which generates binaries > > with mixed code vs data endianness (little endian code, big endian > > data). > > > > Else mismatch between code endianness for the generated signatures and > > data endianness for the RSEQ_SIG parameter passed to the rseq > > registration will trigger application segmentation faults when the > > kernel try to abort rseq critical sections. > > > > 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 > > --- > > tools/testing/selftests/rseq/rseq-arm64.h | 17 +++++++++++++++-- > > 1 file changed, 15 insertions(+), 2 deletions(-) > > > > diff --git a/tools/testing/selftests/rseq/rseq-arm64.h b/tools/testing/selftests/rseq/rseq-arm64.h > > index b41a2a48e965..200dae9e4208 100644 > > --- a/tools/testing/selftests/rseq/rseq-arm64.h > > +++ b/tools/testing/selftests/rseq/rseq-arm64.h > > @@ -6,7 +6,20 @@ > > * (C) Copyright 2018 - Will Deacon > > */ > > > > -#define RSEQ_SIG 0xd428bc00 /* BRK #0x45E0 */ > > +/* > > + * aarch64 -mbig-endian generates mixed endianness code vs data: > > + * little-endian code and big-endian data. Ensure the RSEQ_SIG signature > > + * matches code endianness. > > + */ > > +#define RSEQ_SIG_CODE 0xd428bc00 /* BRK #0x45E0. */ > > + > > +#ifdef __AARCH64EB__ > > +#define RSEQ_SIG_DATA 0x00bc28d4 /* BRK #0x45E0. */ > > +#else > > +#define RSEQ_SIG_DATA RSEQ_SIG_CODE > > +#endif > > + > > +#define RSEQ_SIG RSEQ_SIG_DATA > > > > #define rseq_smp_mb() __asm__ __volatile__ ("dmb ish" ::: "memory") > > #define rseq_smp_rmb() __asm__ __volatile__ ("dmb ishld" ::: "memory") > > @@ -121,7 +134,7 @@ do { \ > > > > #define RSEQ_ASM_DEFINE_ABORT(label, abort_label) \ > > " b 222f\n" \ > > - " .inst " __rseq_str(RSEQ_SIG) "\n" \ > > + " .inst " __rseq_str(RSEQ_SIG_CODE) "\n" \ > > I don't think this is right; the .inst directive _should_ emit the value > in the instruction stream endianness (i.e. LE, regardless of the data > endianness). > > That's certainly the case with the kernel.org crosstool GCC: > > [mark@lakrids:/mnt/data/tests/inst-test]% cat test.c > void func(void) > { > asm volatile(".inst 0xd4000001"); > } > [mark@lakrids:/mnt/data/tests/inst-test]% usekorg 8.1.0 aarch64-linux-gcc -c test.c > [mark@lakrids:/mnt/data/tests/inst-test]% usekorg 8.1.0 aarch64-linux-objdump -d test.o > > test.o: file format elf64-littleaarch64 > > > Disassembly of section .text: > > 0000000000000000 : > 0: d4000001 svc #0x0 > 4: d503201f nop > 8: d65f03c0 ret > [mark@lakrids:/mnt/data/tests/inst-test]% usekorg 8.1.0 aarch64-linux-gcc -mbig-endian -c test.c > [mark@lakrids:/mnt/data/tests/inst-test]% usekorg 8.1.0 aarch64-linux-objdump -d test.o > > test.o: file format elf64-bigaarch64 > > > Disassembly of section .text: > > 0000000000000000 : > 0: d4000001 svc #0x0 > 4: d503201f nop > 8: d65f03c0 ret > > > > Have you tested this? Is there some toolchain that doesn't get this > right? I think that the issue is that the kernel loads the thing to check the signature. RSEQ_SIG_CODE isn't byte-swapped explicitly and is used with .inst. RSEG_SIG_DATA is byte-swapped to ensure that the value passed into the syscall is consistent with what the kernel will load. But yeah, I've just spent the last ten minutes confusing myself with this. Will