From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (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 35EB52D3EC7 for ; Thu, 12 Mar 2026 22:10:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773353442; cv=none; b=MNtLSANJYPiVT9WysYmUi88OoSKQP73/5kXdEdky8dVvYACeA5JUDZxkZTEcx5Vns4nF9kF+K8cLussw+l5wIqXfLqSL8bDgv7yjdjR33ahqdmQNcwcdvn/nAHVowxh1JQxy9xydoBuItjhO/MErTsFQ+Q3BLRV8jT3r8XAlBks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773353442; c=relaxed/simple; bh=fcB7S8zdyMB80BxkOzhXUPYv/BugmVmRKhS/t5lpPzY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=azwiH/vDsQ1oT2QQLCEdgGrlGwj7zrZsUEIi04jIMJVHFS2Ws7kiKtm321W3TA4beisJeO13XnNeaZMsFhq2JYcEJ2hEK0E1FHxvsvdasFJ8L0Gf2q8ZU1ZNRcQEmd1nBs0yNOqz1NPK8i16X/xtdEYOYWiikjBDnROA/Zmixhg= 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=T64DAr2C; arc=none smtp.client-ip=74.125.82.50 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="T64DAr2C" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-1270f10a774so1459c88.1 for ; Thu, 12 Mar 2026 15:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773353440; x=1773958240; 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=m83g+4+U1TG2wOkLOGB03G0wrFd+xSPvILMAfdktFYQ=; b=T64DAr2CyGLHxa0mnvuUc0eyD4/ebC19SoGr9kN6BJisFQUlzS1XRUDIkOkU0SvSdH OgO6FpCzf4th3Mzz1RkLTQPrMHc8jc3EsWTA/VqMv8UW2n8HAeCIvXY3LIPfJC5nnmw/ p1FMro+8pu+1yzJgjLcrgk/vD2ckkETa+g0e+f8jG2hBU0Gfl+s+AsunVkarrUcAfhDD Y06o3W5YePMhhrzEgSOa+Pf7Gl3l8HRThUcT8Ohqvy/CsWJZemOl7dmjscH+u9zUH8Qq 0mMXCsw4GeKmA1c8FlP6x7TIdOgAG/I463Vtev64a+k08rdat831f/Rjr2eaD2N7Cq4q M/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773353440; x=1773958240; 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=m83g+4+U1TG2wOkLOGB03G0wrFd+xSPvILMAfdktFYQ=; b=lUM9CmUEDoPJVJd5CYW/rB4SinQBhYfiqhsOa513C2iVLKDraLJov6WQQO9haB5hNM cCkpryNSQNpGGzSFie1eNeYvslEXx6DS3h7cwb5s4kz3D++rePWfY/7FWEuv0U5qtD+2 rdA2u34TXr+ZpNr7Y2XK4uJ76ljnNVIJfbU9HfqI4ohgW01myhRQ+113oIv3h29ZykYX pJqBPbrPzdkRygbS14cW+s8YbgIIOJLzuHNOYt/5kZ3Lu2chANB0n4KSBZDuNUgpcMWl FkaeApu2NcGIkpv4ZjrEmuTkdf9BE57Rjm9NbsiZgcOEy6HPhA9rqK95znUMf9a5zSvS 0eaQ== X-Forwarded-Encrypted: i=1; AJvYcCU3q16zp1Lr7avfahhW4LHF+7UpdSysTZyV9HvVS+o23aYn3P2X3FqQ7/KfeEGLbPlKUA0xiOrnS00E40w=@vger.kernel.org X-Gm-Message-State: AOJu0YyOqwGVZ2Uo4rjwkY3sqd+ZvtnrhtVIsmLHPG33tFbaLibs9Sum MDVz8MUhVDQTjAx/JG970ZdeWA9R3/HAFzZ3mZP+QCfBYuEdLup87wxeoim1V8CaGA== X-Gm-Gg: ATEYQzzLsQpyUJtaMyVsaGFD/x78kGWrbRY2Fo6mCof0FdVFqL0JoiqXmAkbXuzdNjR L/WKnB0X/G6b/yMyVBYBB8ahalCuoj9nstiq6RGuqQXK3ar4xy5Vn4X30dyzO1vARRhnRNew7s+ HNma7SJPDoid1OQSbsv9qm6g/DTcpUEc1L6P6uaxvrxo655xlF2OGV22CWGhVC4ZqG85wZvBdsE 55Fm0D7m59kCqpqCi3Vp22k12prMZVVi02KDsCjMNf2zFH7ioFINY58N/BErv6Ew6Kx94o2nmhI H+2fkulFLekgX8kv2LUdZx1JcRzhMUicISQJQDrE5iYi8wXd0T74XQMtp8MtWW1m4SR1O7N0CE+ Nl6+0cb1rkcVLQhOdniaF0MpjYDSMjYMP14N12BlnNXXj377FDRbDhMO8gDd1hsGofEKgAy8CgP BvKuK+NfrDMEYtWNrDVUitKsi0dqGPlm6GSn0oE2QsQl76geT1/5ZVfOOKYAyIow== X-Received: by 2002:a05:7023:906:b0:127:67ef:f181 with SMTP id a92af1059eb24-128f5433f9fmr13869c88.25.1773353439639; Thu, 12 Mar 2026 15:10:39 -0700 (PDT) Received: from google.com (154.52.125.34.bc.googleusercontent.com. [34.125.52.154]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-128e7ccd60fsm10487044c88.12.2026.03.12.15.10.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 15:10:38 -0700 (PDT) Date: Thu, 12 Mar 2026 22:10:35 +0000 From: Carlos Llamas To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland , Quentin Perret , Catalin Marinas , James Morse , Will Deacon , Frederic Weisbecker , Peter Zijlstra , Kees Cook , Sami Tolvanen , Andy Lutomirski , Josh Poimboeuf , Steven Rostedt Subject: Re: [PATCH v6 2/2] arm64: implement support for static call trampolines Message-ID: References: <20211105145917.2828911-1-ardb@kernel.org> <20211105145917.2828911-3-ardb@kernel.org> <83c36b0a-7e7d-4651-8e2c-86452c3bd96b@app.fastmail.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: <83c36b0a-7e7d-4651-8e2c-86452c3bd96b@app.fastmail.com> On Thu, Mar 12, 2026 at 07:35:34PM +0100, Ard Biesheuvel wrote: > Hi Carlos, > > On Thu, 12 Mar 2026, at 19:02, Carlos Llamas wrote: > > On Fri, Nov 05, 2021 at 03:59:17PM +0100, Ard Biesheuvel wrote: > >> 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. > >> > >> It is expected that the direct branch instruction will be able to cover > >> the common case. However, given that static call targets may be located > >> in modules loaded out of direct branching range, we need a fallback path > >> that loads the address into R16 and uses 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 .text, 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. > >> > >> Acked-by: Peter Zijlstra > >> Signed-off-by: Ard Biesheuvel > >> --- > > > > I'm starting to testing this out on top of 7.0-rc3... > > > > Please use the v3 I referred to on the thread. The code patching is a bit hairy, and so we should only consider that if there is a real use case for it. > > Same goes for the special handling of the ret0 case - AFAIR, the v3 handles that transparently as it will just use the generic RET0 handler as the target. IIUC, the trampoline tests R16 and returns early if unset. However, for the RET0 case the register would point to __static_call_return0 and then do the indirect call anyway. I suppose CFI is fine with this as like you mentioned, this is "hidden" from the compiler. However, the R16 test seems unnecessary for the RET0 case, as it is always set to _something_ right? Or maybe I'm missing something? Either way, now that I've rebased the patch I can send a... v7? With the required minor tweaks for RET0 and such. -- Carlos Llamas