netdev - Re: [PATCH 3/3] libeth: xdp: Disable generic kCFI pass for libeth_xdp_tx_xmit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251027203630.GA3183341@ax162>
Date: Mon, 27 Oct 2025 13:36:30 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Kees Cook <kees@...nel.org>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Simon Horman <horms@...nel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Russell King <linux@...linux.org.uk>,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Michal Kubiak <michal.kubiak@...el.com>,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
	intel-wired-lan@...ts.osuosl.org,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH 3/3] libeth: xdp: Disable generic kCFI pass for
 libeth_xdp_tx_xmit_bulk()

Hi Przemek,

On Mon, Oct 27, 2025 at 12:09:47PM +0100, Przemek Kitszel wrote:
> sorry, but from regular driver developer perspective, just after reading
> your commit messages, I'm unable to tell what the fix is about, and from
> that follows a bigger issue: how to write code in the future to avoid
> such issues (it would be infeasible to always wait for a LLVM specialist
> to come up with a fix ;))

Sorry about that! To be fair, I am not sure most driver developers would
write something as subtle as this code to get themselves into a
situation where I or another LLVM person would need to come along to fix
it.

> was the tricky case to call __always_inline func from another that was
> marked the same? Would it be also the case if one of the functions would
> not be marked with __always_inline attribute, but still end up inlined?

No, I think the tricky case here is that the code depends on the
compiler being able to turn all these indirect calls, as the (*xmit)()
and (*prep)() parameters in libeth_xdp_tx_xmit_bulk(), into direct calls
through inlining. I find that depending on optimizations for correctness
(i.e., passing the assertion that the result of a equality test can be
proven true or false at compile time) is risky because it can result in
flexible but performant code but it is also sensitive to interactions
with other compiler internals and optimizations, resulting in changes
such as these.

> what would be the cost of the alternative naive solution, to always add
> __nocfi_generic to functions marked __always_inline?
> (technically you would redefine __always_inline to have also
> __nocfi_generic for the config combinations that require that)

No, you would not want to do this because if any indirect call remained
in the inlining chain, there would be no caller side CFI code generation
and that indirect call would automatically fail (if I understand
correctly), which is why commit 894af4a1cde6 ("objtool: Validate kCFI
calls") now validates this rule at compile time for x86_64 (which is not
affected by this issue since it does not use the generic LLVM kCFI pass
like ARM prior to 22.0.0 does).

> sorry for my ignorance of not reading any of the attached URLs

No worries, I am not sure how much more they would help with
understanding the problem, which is subtle. If I can clarify anything
further, please me know but I am not sure it will matter too much since
we will likely just forbid using the generic kCFI pass to avoid this
issue, rather than applying __nocfi_generic.

Cheers,
Nathan