linux-kernel - Re: [RFC PATCH bpf-next 0/2] fentry supports function optimized by complier

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: <a38362a2-a414-45f7-85d6-4be2df15807c@oracle.com>
Date: Wed, 30 Apr 2025 18:58:54 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: Tao Chen <chen.dylane@...ux.dev>, ast@...nel.org, daniel@...earbox.net,
        john.fastabend@...il.com, andrii@...nel.org, martin.lau@...ux.dev,
        eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
        kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com,
        jolsa@...nel.org
Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next 0/2] fentry supports function optimized by
 complier

On 30/04/2025 17:46, Tao Chen wrote:
> The previous discussion about fentry invalid on function optimeized by complier
> is as follows:
> https://lore.kernel.org/bpf/3c6f539b-b498-4587-b0dc-5fdeba717600@oracle.com/
> 
> This seems to be something that pahole needs to resolve. However, Alan
> mentioned that there are many situations involved in this, and he proposed
> that the available_filter_functions_addr can be used to find the address of
> the real function. If we can get the real address from user, maybe this address
> can be used when the function obtained from the BTF is invalid.
> 
> The specific selftest has not been added yet. I just wrote a simple test
> program and ran it.
> 
> This is the initial RFC patch, feedback is welcome.
>

There's some discussion around this in the context of inlines and
optimized functions at [1] that might be of interest. Ultimately for
more complicated cases like this I'd really like to see us have a
name/address relationship encoded in BTF so that we can be clear about
relationships between a function site and its BTF.

The current state of affairs though is that a function will only make it
into BTF if its function signature is consistent with the prototype, so
unless I'm missing something the approach of passing an address to
clarify the relationship seems like a valid one.

It would be great to have a test, can we try adding a function to
bpf_testmod that a compiler will likely optimize to .isra.0 and trace
it? This won't work in all cases, but we could skip the test if the
function isn't optimized as wanted.

[1]
https://lore.kernel.org/dwarves/20250416-btf_inline-v1-0-e4bd2f8adae5@meta.com/





> Tao Chen (2):
>   libbpf: Try get fentry func addr from available_filter_functions_addr
>   bpf: Get fentry func addr from user when BTF info invalid
> 
>  include/linux/bpf.h            |  1 +
>  include/uapi/linux/bpf.h       |  1 +
>  kernel/bpf/syscall.c           |  1 +
>  kernel/bpf/verifier.c          |  9 ++++++
>  tools/include/uapi/linux/bpf.h |  1 +
>  tools/lib/bpf/bpf.c            |  1 +
>  tools/lib/bpf/bpf.h            |  1 +
>  tools/lib/bpf/gen_loader.c     |  1 +
>  tools/lib/bpf/libbpf.c         | 53 ++++++++++++++++++++++++++++++++++
>  9 files changed, 69 insertions(+)
>