From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB76426299 for ; Wed, 4 Feb 2026 00:10:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770163849; cv=none; b=QGOYlTDQ2CtAqKJ4JRBwysYGAcidIxFUYD/Mr3ZTvUBFwImNttROWQCiOQjiy3Udki3eWczJV/xopOc1HzRS0rzfVsu/CP1cg4jB8P471E7iMTBzGjKkv0MAgdSZUu8FY8FkYAWEmtSHqmmp2hTI++QulBdt//wT6nHpIN1yYl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770163849; c=relaxed/simple; bh=z1YMuEvB+WobiLyte1+fX5m3PbH/vX9UhNhRHJWTihk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hunHJcza/3jq8goQojZxO2vspxkK1ZKAnrn7XDprXGfV0muGgHqJVX5Yb2LisQZDJ0d0mjrPM4qJHBZHg5JfbwjK2UbmiKxvQZmUcFhr6KAcqN9zwN0ftEx0lfsKTvb/5gZPaJ40UzgNmHyq5VJrig97uV10DVgIWkYRO3OmCUE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V+PBvUDy; arc=none smtp.client-ip=209.85.218.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V+PBvUDy" Received: by mail-ej1-f68.google.com with SMTP id a640c23a62f3a-b8715a4d9fdso716375366b.0 for ; Tue, 03 Feb 2026 16:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770163841; x=1770768641; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YgKK3ByONbvoWC+ll8e6+//MuLfVWAgLVs4G9qm5feQ=; b=V+PBvUDyGt/7CjKYY7VkuTf7sXZIVk+WxCm8BaQYba55ANb9rSqxpqn6Tii7U1mJRR GJCjA5ubn2+twHjpS8cAn+wxNylmJhJQUhYDCoOFOcyIgm7s0Mx/J2nOG3Sc2Yg+6ClI 2XeRVbFDf9Dha5exgT1htl2Soxy7PyiCxZD7RbuVpNJVmTWH8bTizvguXDV8XnR+Pt5a JxP6BabPJHdZVXIeEdI8smotGbMApPqW9rGlKzb9uhOLEHuJDaD0Q5TMtOUO2zOsp5MX F94eGQnJ6PAn8NaNlE5tVqxH8xMcU1sVJhPqtMTXp1F4fcb9IaZe4KtPHINTaxi0+UbE SPOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770163841; x=1770768641; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YgKK3ByONbvoWC+ll8e6+//MuLfVWAgLVs4G9qm5feQ=; b=auPWWqoq14MJHdCcAtUImck/d2J706LWOmyRhd1+grJAJGav0zH8zfv68x2yNp69iG BNi5CeCOuFdfI5UTyvTx2YDNMbru3t6ApZXBQL5dpPs9FO9Dn/ImMEwLTERdRGIQOysA 1XTtkYBvLKU4LqeIqMuCPbuFFSubgVh0ckdWuHMtoG33pwSYQTueMzwD/l+PsmiM7znI JArlIKK7pKAE49esVtvawCE010y9+f1lWnXo90rHGlDdVJkAPu7Zo+xMXfckNCmGccvt G2L4rIAEXbKTZ3bQ+3iF5m2a/IvVdm4/8F6YXMoT00KKTo7LtSb+eJTWdGca2A14c4Ti XJvA== X-Forwarded-Encrypted: i=1; AJvYcCUZk3Rkxw+6GGxNQytcRJTL3+f4Ksu8O9qd8B4c0DHnnbYW9jKm1MpEtiqfL4EuzQ3ey7y/21Asliez3oE=@vger.kernel.org X-Gm-Message-State: AOJu0YzkvD1D8kxJ9Ss+R7PT6RDwSKaoVYlcT6zmg1yDh+E883a6NZ/r 0xskNbe1GiHjzsxCpakD1kOrriT75zp58JCL+rDNNeAHgO6WtNt4KJV9vgricnys X-Gm-Gg: AZuq6aL3O7LE84P77yslLNaAd20WGsC2heaL5oThdHo3gPqOddcKL41DpRyxxUOvQ7J aScexWPw/p6jZnTtJEwXcbVEgLATu8PC5/2BF5aiZ8RDxG7G21nLjIJNEWqoV8iIgAtNthrOU2O GKrTvPHuQeF3wLfJWWgKUru3oR7T2k6u4ZfDK1aTV/xlTsFpculhoVYZ8DPxa/UfJEewmHHpFCi 9V6QJmiiEzx9P2yDcsiHLso7vlT27DAJcKUADqz6VKFMR6CJ/wRMQhN274LcibMk/2KrfshXT4C GcFzA+lX9AqjmLJcbeS/ii5uiTlfBy59ZguvABb8AsyyBUi73EOnZbL1ubHQyRUMcAClD5dO3QF vtQkvuA067qsdlfTpeciuUQquyhx/beHCcQo3RvYR3upn8vRf4JfYrCqbXdbrdje/itMevztNHu uvrNd67PC67e+i9PaJHaRv+dyZ25wac3LVepBSlLvfsiSDpuS0k4mC X-Received: by 2002:a05:600c:3549:b0:479:2a3c:f31a with SMTP id 5b1f17b1804b1-4830e92cc18mr16039605e9.1.1770157181418; Tue, 03 Feb 2026 14:19:41 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48310858ffdsm906015e9.7.2026.02.03.14.19.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 14:19:41 -0800 (PST) Date: Tue, 3 Feb 2026 22:19:39 +0000 From: David Laight To: "Christophe Leroy (CS GROUP)" Cc: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Segher Boessenkool , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, llvm@lists.linux.dev, kernel test robot Subject: Re: [PATCH] powerpc/uaccess: Fix inline assembly for clang build on PPC32 Message-ID: <20260203221939.059bb903@pumpkin> In-Reply-To: <8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org> References: <8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 3 Feb 2026 08:30:41 +0100 "Christophe Leroy (CS GROUP)" wrote: > Test robot reports the following error with clang-16.0.6: > > In file included from kernel/rseq.c:75: > include/linux/rseq_entry.h:141:3: error: invalid operand for instruction > unsafe_get_user(offset, &ucs->post_commit_offset, efault); > ^ > include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user' > arch_unsafe_get_user(x, ptr, local_label); \ > ^ > arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user' > __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \ > ^ > arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto' > __get_user_size_allowed(x, ptr, size, __gus_retval); \ > ^ > arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed' > case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \ > ^ > arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2' > " li %1+1,0\n" \ > ^ > :7:5: note: instantiated into assembly here > li 31+1,0 > ^ > 1 error generated. > > On PPC32, for 64 bits vars a pair of registers is used. Usually the > lower register in the pair is the high part and the higher register is > the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31 > > In older kernel code inline assembly was using %1 and %1+1 to represent > 64 bits values. However here it looks like clang uses r31 as high part, > allthough r32 doesn't exist hence the error. > > Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so > let's do the same here. > > With that change, the build doesn't fail anymore and a disassembly shows > clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and > r30/r31: Isn't it all horribly worse than that? It only failed because clang picked r31, but if can pick two non-adjacent registers might it not pick any pair. In which case there could easily be a 64bit get_user() that reads an incorrect value and corrupts another register. Find one and you might have a privilege escalation. David > > Disassembly of section .fixup: > > 00000000 <.fixup>: > 0: 38 a0 ff f2 li r5,-14 > 4: 3a 20 00 00 li r17,0 > 8: 3a 40 00 00 li r18,0 > c: 48 00 00 00 b c <.fixup+0xc> > c: R_PPC_REL24 .text+0xbc > 10: 38 a0 ff f2 li r5,-14 > 14: 3b e0 00 00 li r31,0 > 18: 39 c0 00 00 li r14,0 > 1c: 48 00 00 00 b 1c <.fixup+0x1c> > 1c: R_PPC_REL24 .text+0x144 > > Reported-by: kernel test robot > Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/ > Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()") > Signed-off-by: Christophe Leroy (CS GROUP) > --- > I set Fixes: tag to the commit that recently replaced %1+1 by %L1 in the main part of the macro as the fix would be uncomplete otherwise but the problem has been there since commit 2df5e8bcca53 ("powerpc: merge uaccess.h") > --- > arch/powerpc/include/asm/uaccess.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h > index ba1d878c3f404..570b3d91e2e40 100644 > --- a/arch/powerpc/include/asm/uaccess.h > +++ b/arch/powerpc/include/asm/uaccess.h > @@ -255,7 +255,7 @@ __gus_failed: \ > ".section .fixup,\"ax\"\n" \ > "4: li %0,%3\n" \ > " li %1,0\n" \ > - " li %1+1,0\n" \ > + " li %L1,0\n" \ > " b 3b\n" \ > ".previous\n" \ > EX_TABLE(1b, 4b) \