From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 990C7377EDF for ; Sat, 30 May 2026 21:19:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780175967; cv=none; b=MUi9df33h58jDLwIfHCDrC81agpGA1ADzhMyQOzLhS9oiiiyXCkYuyqs8OnVyH2tcj+f8Ip3OE9dWnIj/HH1BgiJMUr0tgjOfaj/dS3+1HWxHTn31sjmafAykI1Rm7aBg9rw2Z4elIOyFEij4+bnlADhnsXkzFHS4q0hnWVWuN8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780175967; c=relaxed/simple; bh=I9Udm9Yo1c0vCK7YiKGXpVtlOK9+rwu8IYxI4GRRnrI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EPJv+uTjhS3E7l+/esRb8tPZ7ngjpOHswdeM2AA7ZX3OrJwc/7k/nyiRTP82QVbsYFTyPEYYdasp9ba5JGbLj+v9uehARqCvLU8eeX806hxyAyNuhYf18U4xsuWmHeFFlTPwPcIBUCUmbcHR5tlNOMig5wyCF2zM93WZzAIvNEo= 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=GqT/J1AU; arc=none smtp.client-ip=209.85.221.53 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="GqT/J1AU" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-45ef6565cfdso599070f8f.0 for ; Sat, 30 May 2026 14:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780175963; x=1780780763; 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=5kd8Ei42IzmODs1+3O5kaicD7KHsdMF4sqDHyZmAfuM=; b=GqT/J1AU+uozbSriocPLVTuOhScqImMAYooDikU13voVf1668nADunsElNFmFUvDKI f/a+b8nWV69qOI9Bhz+Tpq8rEVRXDfeHv1jSNpt2sX+yTm9Y5LZDi1sexEkRu9oCht3s 8p/emWSN/OFNNYx2XD+7ls60ZgyWJE0INasUAmmMDwBY22YL8V+byWShmHnzoXVawkYR 5N7F3appt0RSsnSAA6u01TUNPFi/lV1ovqppCOhaczOsP4DcQ8qhnxuue5YByduVg4AI uQXRftzqcIHVD06KFQ4OkfbCOaAZt3kwUj/aruMcGiLVYe6tLPeEZ7T8B1nTo495zIsQ TvOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780175963; x=1780780763; 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=5kd8Ei42IzmODs1+3O5kaicD7KHsdMF4sqDHyZmAfuM=; b=CYH9ac+mp5oX5QM2iNvBYWZqDW7x2Q8FQLUZ1kszzhVtGlCXLAGQ37PfZ1rFuAwNn1 Op+Mm35iRChMEZyk4+y8pKigOszGRcxqBRMoLcyBiGSWwIERA0vvCdojqTIrm1/OgL1A O5jPYMUHzRkPutodmlFDWT1OFG6JU5NHf4Wh6z82CWERElCAkk3WHqGSOtqyVukne+D1 LoEaiXo7TIpqFx9gUZZkg6mEYrPFKAw2t5nuvRiCKBmUYouJNx77Nnln6eoaoGltDdwR hRLhqXyS0O9JU0N/+zldNSKUymrGvSFRD9bPfvWPRuSqCNiFitskA2Djm5MACT84YVYL ZdRw== X-Forwarded-Encrypted: i=1; AFNElJ9z04mjE4vspa902Z+gNrnpWazqOgHmcR7e05TRbl13k+3X/PTb/uPjVWIEAkrhYjzbCo6U4jUXybzm1eo=@vger.kernel.org X-Gm-Message-State: AOJu0YxOySOq28+pRFrIPzCgwo9huGpATifRYgwdrM4tEdziNNAFN5/q BqLX54DL4JmL0ozSjNOYHfMDfo5IdpJA+OviAcSXs3f/6kvF2XhUGpsA X-Gm-Gg: Acq92OEDUYiIpJcpRYFWLQDXGyf5qMF8kN7SRmUlqcMsCJVXQKIC+ZLC0pxRWZcyFlb JFBSDB6DG1Q4Oq1Ud6shZ2REhUOmMBOp5/LJGzuabtwWTYENe47ZZlUqKdBPDOmieNGpPZbIK1+ 6lh51kcXOuFvvQ/Q9usdn+JM5/lsOkSWHG83wlSmihr1WE3CoLbwU02Aw0NKbkoAtyaNh+2cq7T WGFniCbliTmx20ZXchOP1k1Y9chYGAFQLYVBpnY4la8ijQ1vnPEj7VtqdaPkAbyOaJ3jggahpNQ 5+PHz1kDn71aCnP3RHnbcjp++oOhU9qVTYqUcNEdtG72E94n14idLbgvA6ltdwJgjc0YJ5XHkvw QuS11lBcLy0kT8SS7j8wOmArIOnuJdwM8aLOD261GioDXoxrXUQsmZIyhOatzP7Hhj2KoIODaqL tVeZaOKs1ScDcE33O8ldxWhJ15nDZaQZlIDtS1mVw+x6aESvVU5gOYb7s4PudWBDu+HWAeebtoG 061yQ1IKw== X-Received: by 2002:a05:6000:cc3:b0:45e:da7f:b26a with SMTP id ffacd0b85a97d-45ef6b742ccmr6735580f8f.33.1780175962826; Sat, 30 May 2026 14:19:22 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef354cf0dsm13276363f8f.17.2026.05.30.14.19.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 May 2026 14:19:22 -0700 (PDT) Date: Sat, 30 May 2026 22:19:21 +0100 From: David Laight To: Steven Rostedt Cc: Peter Zijlstra , Eva Kurchatova , mhiramat@kernel.org, linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, jpoimboe@kernel.org, samitolvanen@google.com Subject: Re: [PATCH] tracing: fix CFI violation in probestub helper Message-ID: <20260530221921.50d958cf@pumpkin> In-Reply-To: <20260529195134.37d4f5cc@fedora> References: <20260524154301.21119-1-eva.kurchatova@virtuozzo.com> <20260528164902.1bb985f3@gandalf.local.home> <20260529200826.GO3493090@noisy.programming.kicks-ass.net> <20260529195134.37d4f5cc@fedora> 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 Fri, 29 May 2026 19:51:34 -0400 Steven Rostedt wrote: > On Fri, 29 May 2026 22:08:26 +0200 > Peter Zijlstra wrote: > > > On Thu, May 28, 2026 at 04:49:02PM -0400, Steven Rostedt wrote: > > > On Sun, 24 May 2026 18:43:01 +0300 > > > Eva Kurchatova wrote: > > > > > > > When multiple callbacks are registered on the same tracepoint, probestub > > > > will be indirectly called via traceiter helper. > > > > > > > > Pointer to probestub callback resides in __tracepoints section, which is > > > > excluded from ENDBR checks in objtool. Pointers to regfunc/unregfunc > > > > callbacks reside in extended structure however, which is not affected. > > > > > > > > Registering multiple callbacks will result in a #CP exception due to > > > > missed ENDBR in __probestub helper on a CFI-enabled machine. > > > > > > > > Fix this by adding CFI_NOSEAL annotation to probestub declaration. > > > > > > > > Fixes: d5173f753750 ("objtool: Exclude __tracepoints data from ENDBR checks") > > > > Signed-off-by: Eva Kurchatova > > > > > The only place the function address lives is in that __tracepoint > > section. Since that is explicitly excluded by objtool, it figures there > > are no actual references to __probestub and the function goes on the > > seal list and the kernel explicitly scribbles the ENDBR on boot. > > > > Then, if it ever gets used on an IBT enabled host, *boom*. > > That makes much more sense. > > > > > I agree it would've perhaps been clearer if there was part of a splat in > > the changelog, but the issue is real afaict. > > > > Also, I do think this: > > > > > > @@ -356,6 +357,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p) > > > > void __probestub_##_name(void *__data, proto) \ > > > > { \ > > > > } \ > > > > + CFI_NOSEAL(__probestub_##_name); \ > > > > DEFINE_STATIC_CALL(tp_func_##_name, __traceiter_##_name); > > > > > > > > #define DEFINE_TRACE_FN(_name, _reg, _unreg, _proto, _args) \ > > > > could do with a comment, explaining why it wants the NOSEAL. > > Yes. > > Thus, the above change log is totally incorrect and should be updated to: > > tprobes uses a stub function of the tracepoint to allow fprobes to > attach to the tracepoint call site and have access to its arguments. > The stub function is called __probestub_##_name() and is only > referenced as a pointer in the tracepoint structure so that the > tprobe can have access to it. > > The issue is that the probstub function is only referenced in the > __tracepoint section and objtool thinks nothing calls it. Since it > explicitly excludes the __tracepoint section, objtool thinks there > are no callers so it puts the probstub function into the seal list > and then the kernel scrubs its ENDBR on boot. > > This becomes an issue if someone were to use a tprobe which will > register the probestub as a callback to the tracepoint so that a > fprobe may attach to it and get access to the arguments. Without the > ENDBR it will make the kernel go BOOM! > > > Then have a comment in the patch with: > > void __probestub_##_name(void *__data, proto) \ > { \ > } \ > +/* \ > + * The probestub is only used for tprobes and not referenced \ > + * anywhere else. This causes objtool to think it's not called \ > + * at all and will add it to the seal list which will remove \ > + * the ENDBR causing issues if a tprobe is ever used. \ > + */ \ Isn't the sense of that all wrong? Maybe: Annotate the protosub 'CFI_NOSEAL' to stop objtool requesting the kernel remove the ENDBR because the only references to the function are in the __tracepoint section that objtool doesn't scan. -- David > +CFI_NOSEAL(__probestub_##_name); \ > DEFINE_STATIC_CALL(tp_func_##_name, __traceiter_##_name); > > > -- Steve >