Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2175680pxb; Sun, 31 Oct 2021 09:26:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/13CyHQRfNCBHv9E2z5tWjsatXHghhVHGAX3H5InRZP33UeX5dY4sCW0kKmGhQyu1bWfd X-Received: by 2002:a05:6638:1304:: with SMTP id r4mr17693925jad.41.1635697618915; Sun, 31 Oct 2021 09:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635697618; cv=none; d=google.com; s=arc-20160816; b=WljbVCvHWVOZY7CkkhhJ5wqqjManrtUEVrmeD+8WDf1mMY5sAZ/1WpBz8Olzj3g4JS 3xj6Clkuz9J4LYITfv8+ixfyg3yzPjo8Z4Yv1LU9SQoHw5U4tjUeHNo2APbMfGK3qYs6 jwlR9as3q8hMUtqXq7/sU5qK5Puk7GUkQLMSjCe+vJBwU5cJW3T1FvhKE8BlCNYsfPlU 8xJzIZtFfS2T+bgObuxV+nQbw9B3mcq4n7jzxjdvdAypdMflLO8D2/mEJz49fgyCvJTl Yv21okNvDjZjMDZR6buSf0ugjMB4nN1jUxvHn7b7g63CfA9ElPT82uPbBbRtVwSIAkce 0hKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Msrp1l+6mDAXogQRFIvmwpBFD0SJzqKLmR0xOAJaNnE=; b=Wzzr3Ws+B01OJedeHiuh11U+aGKoj3C4Xw8pKFQAkHt31fmD0flhjy9HzpJxyL7geE Qjip6XDmRP+21dGid0BN1aG7mRJ3jKRgozzaX6Vem+NEIq2NGdnJY4GQ9LubZNlfL49L 4bz5knBC1DGrfERa2xKJBfHk0ibjjHOiLJtMM/wAyfp6C3mDxJTBQ7bsJ1kyNcUpb2je p7H92SvR9U9nT1wWpIHrGoGpiNsf0NDPVGBOq12oJoQm+cW7vcPmv+WvIs59/jlRhL7t Xz+EtF9Dcel0STIK+Nr1aa4YJx6nejIWdvHe0TUgPPvVeweRm9yNUspbM/VgSkRu0P8B 29SA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NoB5v3ay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f15si6018662ilu.96.2021.10.31.09.26.35; Sun, 31 Oct 2021 09:26:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NoB5v3ay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229936AbhJaQ06 (ORCPT + 99 others); Sun, 31 Oct 2021 12:26:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:34730 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbhJaQ06 (ORCPT ); Sun, 31 Oct 2021 12:26:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0F07C60FC1; Sun, 31 Oct 2021 16:24:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635697466; bh=jpYWVVXaXaqn2deTdXgq4vDHJddb9QdR0vfJzy/9xX0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NoB5v3ayLk1+zKhjY4jXxLc9RwN9Xm4D7CsoFLntTApdwIv3LPAQ2MCpsi/fMBlme 3+WyFfSsZ7UCo7OiBW5fmecnIk04VfjS+h98w3F37r3GaQWMIkcWUMTAn9lc6QbtJJ LWxhI+Nlo7Sz8Gt6mvI0wGMcoC8VNzw8EpnQFSjVEeMf9T9DeqIhzaqz0X2DSPpJlD +jr7qOGKK4tLozHT+yDvnalAnrloxbFqoei6Y5AHPGtvS1zl8Vk/6sehh+haEg2pAE QB7zr0afomR0pPW/KSTNxLQl5RJ+p9WygIciPfJUlwpFbCSnQ6DT7XGivHfP21zfJT ceq73t+gEMRdg== Received: by mail-oo1-f53.google.com with SMTP id t7-20020a4aadc7000000b002b8733ab498so5422914oon.3; Sun, 31 Oct 2021 09:24:26 -0700 (PDT) X-Gm-Message-State: AOAM531NEmlVaoY/SJe18mzplICptYeyv0jXWdcDEjTPt/M8Pp39sO1Z xiaZ6ehf4YhCWqwHgjBE3EQv/1uxPiKVF3IuGnc= X-Received: by 2002:a4a:e1a3:: with SMTP id 3mr10141000ooy.32.1635697465245; Sun, 31 Oct 2021 09:24:25 -0700 (PDT) MIME-Version: 1.0 References: <20211027124852.GK174703@worktop.programming.kicks-ass.net> <20211029200324.GR174703@worktop.programming.kicks-ass.net> <20211030074758.GT174703@worktop.programming.kicks-ass.net> <20211030180249.GU174703@worktop.programming.kicks-ass.net> In-Reply-To: From: Ard Biesheuvel Date: Sun, 31 Oct 2021 17:24:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] static_call,x86: Robustify trampoline patching To: Peter Zijlstra Cc: Sami Tolvanen , Mark Rutland , X86 ML , Kees Cook , Josh Poimboeuf , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, Linux Kernel Mailing List , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Oct 2021 at 20:55, Ard Biesheuvel wrote: > > On Sat, 30 Oct 2021 at 20:03, Peter Zijlstra wrote: > > > > On Sat, Oct 30, 2021 at 07:19:53PM +0200, Ard Biesheuvel wrote: > > > I just realized that arm64 has the exact same problem, which is not > > > being addressed by my v5 of the static call support patch. > > > > Yeah, it would. > > > > > As it turns out, the v11 Clang that I have been testing with is broken > > > wrt BTI landing pads, and omits them from the jump table entries. > > > Clang 12+ adds them properly, which means that both the jump table > > > entry and the static call trampoline may start with BTI C + direct > > > branch, and we also need additional checks to disambiguate. > > > > I'm not sure, why would the static_call trampoline need a BTI C ? The > > whole point of static_call() is to be a direct call, we should never > > have an indirect call to the trampoline, that would defeat the whole > > purpose. > > This might happen when the distance between the caller and the > trampoline is more than 128 MB, in which case we emit a veneer that > uses an indirect call as well. So we definitely need the landing pad > in the trampoline. Something like the below seems to work to prevent getting the wrong trampoline address into arch_static_call_transform: diff --git a/arch/x86/include/asm/static_call.h b/arch/x86/include/asm/static_call.h index cbb67b6030f9..c3704ea21bee 100644 --- a/arch/x86/include/asm/static_call.h +++ b/arch/x86/include/asm/static_call.h @@ -25,7 +25,9 @@ asm(".pushsection .static_call.text, \"ax\" \n" \ ".align 4 \n" \ ".globl " STATIC_CALL_TRAMP_STR(name) " \n" \ + ".globl " STATIC_CALL_TRAMP_P_STR(name) " \n" \ STATIC_CALL_TRAMP_STR(name) ": \n" \ + STATIC_CALL_TRAMP_P_STR(name) ": \n" \ insns " \n" \ ".type " STATIC_CALL_TRAMP_STR(name) ", @function \n" \ ".size " STATIC_CALL_TRAMP_STR(name) ", . - " STATIC_CALL_TRAMP_STR(name) " \n" \ diff --git a/include/linux/static_call.h b/include/linux/static_call.h index 19dc210214c0..46777a3395d3 100644 --- a/include/linux/static_call.h +++ b/include/linux/static_call.h @@ -143,7 +143,7 @@ */ extern void arch_static_call_transform(void *site, void *tramp, void *func, bool tail); -#define STATIC_CALL_TRAMP_ADDR(name) &STATIC_CALL_TRAMP(name) +#define STATIC_CALL_TRAMP_ADDR(name) &STATIC_CALL_TRAMP_P(name) #else #define STATIC_CALL_TRAMP_ADDR(name) NULL diff --git a/include/linux/static_call_types.h b/include/linux/static_call_types.h index 5a00b8b2cf9f..98a448f5ae45 100644 --- a/include/linux/static_call_types.h +++ b/include/linux/static_call_types.h @@ -18,6 +18,8 @@ #define STATIC_CALL_TRAMP(name) __PASTE(STATIC_CALL_TRAMP_PREFIX, name) #define STATIC_CALL_TRAMP_STR(name) __stringify(STATIC_CALL_TRAMP(name)) +#define STATIC_CALL_TRAMP_P(name) __PASTE(STATIC_CALL_TRAMP(name), _p) +#define STATIC_CALL_TRAMP_P_STR(name) __stringify(STATIC_CALL_TRAMP_P(name)) /* * Flags in the low bits of static_call_site::key. */ @@ -36,7 +38,8 @@ struct static_call_site { #define DECLARE_STATIC_CALL(name, func) \ extern struct static_call_key STATIC_CALL_KEY(name); \ - extern typeof(func) STATIC_CALL_TRAMP(name); + extern typeof(func) STATIC_CALL_TRAMP(name); \ + extern u8 STATIC_CALL_TRAMP_P(name); #ifdef CONFIG_HAVE_STATIC_CALL That leaves the 'func' argument, which ideally should not go through the jump table either, but at least it is not terminally broken there.