From patchwork Sun Jan 23 19:31:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mathieu Desnoyers X-Patchwork-Id: 534498 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09712C433F5 for ; Sun, 23 Jan 2022 19:32:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233368AbiAWTcU (ORCPT ); Sun, 23 Jan 2022 14:32:20 -0500 Received: from mail.efficios.com ([167.114.26.124]:59614 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbiAWTcT (ORCPT ); Sun, 23 Jan 2022 14:32:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id E826533CF67; Sun, 23 Jan 2022 14:32:16 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id h6IzOI8ey4hQ; Sun, 23 Jan 2022 14:32:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id BEC2B33CF66; Sun, 23 Jan 2022 14:32:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com BEC2B33CF66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1642966335; bh=zzzUGnQTdXdaz95fMULZVWKGcJHsP+p8zelCLBiuEaA=; h=From:To:Date:Message-Id; b=RCQIiVl0Wyi30ejckwUYhClp8AMBdlKC2h4B+7YvKGGwsgUBN2P2qZISEu1A02zJy 1zSTr9GESwsLAkduavn4r/MqRl61UCPqmjgp+qvEaDAkrlRTtw7O0JkwsJGpLeQwBZ CTf49W7bC3sVbXst+qVk4gNk4TZdglTydQJpWDMeWMSzLjyIXq2t3TB9RqkJ/EbD7c azOztK9yq8+friXdUSnHmUkHSFk51san3eS/XeAZ8+WQC14Lu0cK7tsqoHLyWU2gMx 11sGO6iQr4R+AyydP9rEmUDE7pK1VtPN6WLSEJwgieaJOTZrN15DzRuCwo3OggOdmS U5xGqlvzOsqvQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NbSC7Oyozs_q; Sun, 23 Jan 2022 14:32:15 -0500 (EST) Received: from localhost.localdomain (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) by mail.efficios.com (Postfix) with ESMTPSA id 1D2BE33D136; Sun, 23 Jan 2022 14:32:15 -0500 (EST) From: Mathieu Desnoyers To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, stable@vger.kernel.org, Mathieu Desnoyers , Florian Weimer , Andy Lutomirski , Dave Watson , Andrew Morton , Russell King , Andi Kleen , Christian Brauner , Ben Maurer , Steven Rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes Subject: [RFC PATCH] rseq: Fix broken uapi field layout on 32-bit little endian Date: Sun, 23 Jan 2022 14:31:54 -0500 Message-Id: <20220123193154.14565-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The rseq rseq_cs.ptr.{ptr32,padding} uapi endianness handling is entirely wrong on 32-bit little endian: a preprocessor logic mistake wrongly uses the big endian field layout on 32-bit little endian architectures. Fortunately, those ptr32 accessors were never used within the kernel, and only meant as a convenience for user-space. While working on fixing the ppc32 support in librseq [1], I made sure all 32-bit little endian architectures stopped depending on little endian byte ordering by using the ptr32 field. It led me to discover this wrong ptr32 field ordering on little endian. Because it is already exposed as a UAPI, all we can do for the existing fields is document the wrong behavior and encourage users to use alternative mechanisms. Introduce a new rseq_cs.arch field with correct field ordering. Use this opportunity to improve the layout so accesses to architecture fields on both 32-bit and 64-bit architectures are done through the same field hierarchy, which is much nicer than the previous scheme. The intended use is now: * rseq_thread_area->rseq_cs.ptr64: Access the 64-bit value of the rseq_cs pointer. Available on all architectures (unchanged). * rseq_thread_area->rseq_cs.arch.ptr: Access the architecture specific layout of the rseq_cs pointer. This is a 32-bit field on 32-bit architectures, and a 64-bit field on 64-bit architectures. Link: https://git.kernel.org/pub/scm/libs/librseq/librseq.git/ [1] Fixes: ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union, update includes") Signed-off-by: Mathieu Desnoyers Cc: Florian Weimer Cc: Thomas Gleixner Cc: linux-api@vger.kernel.org Cc: Peter Zijlstra Cc: Boqun Feng Cc: Andy Lutomirski Cc: Dave Watson Cc: Paul Turner Cc: Andrew Morton Cc: Russell King Cc: "H . Peter Anvin" Cc: Andi Kleen Cc: Christian Brauner Cc: Ben Maurer Cc: Steven Rostedt Cc: Josh Triplett Cc: Linus Torvalds Cc: Catalin Marinas Cc: Will Deacon Cc: Michael Kerrisk Cc: Joel Fernandes Cc: Paul E. McKenney --- include/uapi/linux/rseq.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h index 9a402fdb60e9..68f61cdb45db 100644 --- a/include/uapi/linux/rseq.h +++ b/include/uapi/linux/rseq.h @@ -108,6 +108,12 @@ struct rseq { */ union { __u64 ptr64; + + /* + * The "ptr" field layout is broken on little-endian + * 32-bit architectures due to wrong preprocessor logic. + * DO NOT USE. + */ #ifdef __LP64__ __u64 ptr; #else @@ -121,6 +127,23 @@ struct rseq { #endif /* ENDIAN */ } ptr; #endif + + /* + * The "arch" field provides architecture accessor for + * the ptr field based on architecture pointer size and + * endianness. + */ + struct { +#ifdef __LP64__ + __u64 ptr; +#elif defined(__BYTE_ORDER) ? (__BYTE_ORDER == __BIG_ENDIAN) : defined(__BIG_ENDIAN) + __u32 padding; /* Initialized to zero. */ + __u32 ptr; +#else + __u32 ptr; + __u32 padding; /* Initialized to zero. */ +#endif + } arch; } rseq_cs; /*