From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (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 74C853C9EC1 for ; Fri, 13 Mar 2026 16:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773420544; cv=none; b=iDI8/wv0dDMGmh4DErNQqTaUisg++qH82+3jHsEBr008+NpNqf1hsy5wMWy43h0wZZfUaBS2IPSFILCghzRlMZDpOa3dqEM0ytYuEQnwIAAYlGDjWxKCY9TqQIEMocHI712u/5gz95uORouSFnUhlsNmnqdNudDkpQCwbVLRRFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773420544; c=relaxed/simple; bh=BJZplKNgUjUMq8LSlZGS7u5GyhmWuDESECIa/u7oCGc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M0xXMLqVtukYLW32QYg+qocsq8peeVujRPL0o+bPEq8egnWPnlcoKanGk1BpkrLug7OFFcm6KZi4ldepzR1R7+k7azgtPIXDDAUK7GW7sA3MVWtUXgcbotFP4LoEgUYVvKU+vSffBoN1lIEcPHI9Z46C/D+AoqwSlZ333tT2D30= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=qybKkfcv; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qybKkfcv" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2aea4ebb048so535ad.1 for ; Fri, 13 Mar 2026 09:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773420543; x=1774025343; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=w1lelRKFJxXRBLVjsXJIfqPbatv27C9RsGd3yY01pM4=; b=qybKkfcvAEND19qh43ouIaAzG7c17yqAdWEgmkgl5jhPmvBwSEyu/XaFZ0z9b6p9sj t512mjjYm+CY5uWaDVUS9Hiw6Q8N2IxaLwNWzKP64SR+2H6xK/UxC5Cpd0w08gDJT6G0 hCKY+XPE/HdCXxLa1HkSYKcbFHkLQIOf1zKQRQ/7wngxzOQDAT9owny0jp11v22iP+KG +WqQH05y2W6va6vw6MTXUqGn2TtxvAEWhpY2aimZE5XARC13J81R/WoQPhhxh4jOeAfx mJxMp8U8PbvnjiOeHf9XW+/KvqBfS8vtdOHf5Afnm+pgu/ZDLoUTfGiClmxj2tQrGj9K xk/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773420543; x=1774025343; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w1lelRKFJxXRBLVjsXJIfqPbatv27C9RsGd3yY01pM4=; b=hLh5+sQq1q63GE/GJ2WqwJYHjPjatHxKFZR3K5y4+DFtKLkT26vhEyxDvxxdK6ENo0 DX2b3PU5+KHYssWHK5LrO0tY01AQ3F26x9Y6iAVWP9gGe+PH606FjnXJ2WfzEetzQTqs 3h1hK3ENG/TItB0JYvCYFCILt9RwLTy/qJd/c0GzmdgWySF7nJgk37N6z+J1zATQplQ9 QLdUhb5B7ZEiDFlqLEVhsUCzgKSBpBTr9pHr2PmA5muJwddpb8AsQo/o6AwV9coHlySi 1GYqE2bJeDVzCOghQba67zceyL/3KuHYQ3qGRfumWgdkBnhBBUOvZt9FBWY5dRaWRiaB BYqg== X-Forwarded-Encrypted: i=1; AJvYcCUX0KlI3YuUoB4xrMUn853xFV9pZz9T0X+n1i0Dlta1VRPR9lkivvWWLS9jgX1p/kzL+MLaq4MlztXCTUI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx9EKcF4S3DnAnGj/rPGvCtC0Eys5RblqX26AnzqynFpeyFDQgl c8KimHkzvJ3lnpQQrH548eC59I7yLUaN7WaZicYCrR661zf4rgRrMNeEB/2DzC+whQ== X-Gm-Gg: ATEYQzxezIsbvQ6BwzjnAaTIv+gQWQCEQTP0g+pR3ahvLz0R8Z99EAu68VeEik5UtBj VZd/RTzmsxSa8Hks0FP/RXWWcKrWrKUk9GrTKBcBFDbT+W5P23b/XUr7ydNM+NG1SKbuj4y6PVb tPyFgA3c1qrJf7k7Mctcg+juYJUijDqUUnf8L5gmY80noiftd59NP7evxBhSljg7naK7VJIAzU6 23SFr12bq53dWDkiyzAcrpO+W+QWxeSTDIoKWgo8nCyY8Skw1WWw7T515619qlW2dlkJcVcrTSx TCnkEkD8We/F0bBtZ8sz3JrN/TAphXfXjLYr9fA+m2ev+xeqWVVecwXO/uauDgncxokhaFJykLU YZtFe/0kfUxZPrXeTSWU4tULE7++TujAwmfMiZ3YGZLAH6oLmzGQMXbzuV/d5/DbKBfV2dfHZv2 keG55g1HUsWKnvXoqksf0L2P0KhntlNkU96qztnW+Vgfs6QMtVhDqUwoCz/aW8wMnRIYE= X-Received: by 2002:a17:902:e809:b0:2ae:4e8e:954e with SMTP id d9443c01a7336-2aecd55f847mr2514455ad.5.1773420542161; Fri, 13 Mar 2026 09:49:02 -0700 (PDT) Received: from google.com (197.23.125.34.bc.googleusercontent.com. [34.125.23.197]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35a22d21cf2sm1445876a91.2.2026.03.13.09.49.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2026 09:49:01 -0700 (PDT) Date: Fri, 13 Mar 2026 16:48:56 +0000 From: Sami Tolvanen To: Carlos Llamas Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Peter Zijlstra , Josh Poimboeuf , Ard Biesheuvel , Mark Rutland , Kees Cook , Quentin Perret , Steven Rostedt , Will McVicker , Sean Christopherson , kernel-team@android.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7] arm64: implement support for static call trampolines Message-ID: <20260313164856.GB213695@google.com> References: <20260313061852.4025964-1-cmllamas@google.com> 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-Disposition: inline In-Reply-To: <20260313061852.4025964-1-cmllamas@google.com> On Fri, Mar 13, 2026 at 06:18:52AM +0000, Carlos Llamas wrote: > From: Ard Biesheuvel > > Implement arm64 support for the 'unoptimized' static call variety, which > routes all calls through a single trampoline that is patched to perform a > tail call to the selected function. > > Since static call targets may be located in modules loaded out of direct > branching range, we need to use a ADRP/ADD pair to load the branch target > into R16 and use a branch-to-register (BR) instruction to perform an > indirect call. Unlike on x86, there is no pressing need on arm64 to avoid > indirect calls at all cost, but hiding it from the compiler as is done > here does have some benefits: > - the literal is located in .rodata, which gives us the same robustness > advantage that code patching does; > - no performance hit on CFI enabled Clang builds that decorate compiler > emitted indirect calls with branch target validity checks. > > Cc: Peter Zijlstra (Intel) > Signed-off-by: Ard Biesheuvel > Signed-off-by: Carlos Llamas Does this need a Co-developed-by tag as well? > --- > v7: > - Took Ard's v3 patch (as it leaves the code patching logic out) and > rebased it on top of mainline 7.0-rc3. > - Dropped the changes to arch/arm64/lib/insn.c and instead switched to > the (now) existing aarch64_insn_write_literal_u64(). > - Added the RET0 trampoline define which points to the generic stub > __static_call_return0. > - Made the HAVE_STATIC_CALL conditional on CFI as suggested by Ard. > - Added .type and .size sections to the trampoline definition to > support ABI tools. > > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/static_call.h | 33 ++++++++++++++++++++++++++++ > arch/arm64/kernel/Makefile | 1 + > arch/arm64/kernel/static_call.c | 20 +++++++++++++++++ > arch/arm64/kernel/vmlinux.lds.S | 1 + > 5 files changed, 56 insertions(+) > create mode 100644 arch/arm64/include/asm/static_call.h > create mode 100644 arch/arm64/kernel/static_call.c > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 38dba5f7e4d2..9ea19b74b6c3 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -252,6 +252,7 @@ config ARM64 > select HAVE_RSEQ > select HAVE_RUST if RUSTC_SUPPORTS_ARM64 > select HAVE_STACKPROTECTOR > + select HAVE_STATIC_CALL if CFI > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_KPROBES > select HAVE_KRETPROBES > diff --git a/arch/arm64/include/asm/static_call.h b/arch/arm64/include/asm/static_call.h > new file mode 100644 > index 000000000000..331580542fd4 > --- /dev/null > +++ b/arch/arm64/include/asm/static_call.h > @@ -0,0 +1,33 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_STATIC_CALL_H > +#define _ASM_STATIC_CALL_H > + > +#define __ARCH_DEFINE_STATIC_CALL_TRAMP(name, target) \ > + asm(" .pushsection .static_call.text, \"ax\" \n" \ > + " .align 3 \n" \ > + " .globl " STATIC_CALL_TRAMP_STR(name) " \n" \ > + STATIC_CALL_TRAMP_STR(name) ": \n" \ > + " hint 34 /* BTI C */ \n" \ It doesn't really matter either way, but do we still support toolchains that don't understand "bti c"? Otherwise looks good to me, and definitely a much better way to solve this issue: Reviewed-by: Sami Tolvanen Sami