linux-kernel - Re: [PATCH bpf-next] bpf: uapi: Document front truncation in bpf_d

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] [day] [month] [year] [list]

Message-ID: <CAADnVQLxotSL66rxfJpO0Khh1X4uFeytR7axLGVmkg1HL2FnNw@mail.gmail.com>
Date: Mon, 30 Dec 2024 15:15:36 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Eddy Z <eddyz87@...il.com>, 
	Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next] bpf: uapi: Document front truncation in bpf_d_path()

On Mon, Dec 30, 2024 at 1:55 PM Daniel Xu <dxu@...uu.xyz> wrote:
>
> bpf_d_path() will truncate the resolved path from the front if the
> provided buffer is too small. This is somewhat non-intuitive but makes
> sense when you think about it. So document it.
>
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
>  include/uapi/linux/bpf.h       | 4 ++++
>  tools/include/uapi/linux/bpf.h | 4 ++++
>  2 files changed, 8 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 2acf9b336371..91218c5fd207 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -4845,6 +4845,10 @@ union bpf_attr {
>   *             including the trailing NUL character. On error, a negative
>   *             value.
>   *
> + *             If *buf* is too small, the resolved path is truncated from
> + *             the front and -ENAMETOOLONG is returned. The buffer is valid
> + *             in this case.
> + *

I think this is overkill to add to uapi header.
Above is an implementation detail.
Highly unlikely at this point, but it may change.
While the above description in the uapi file may prompt unnecessary
concerns if/when implementation changes.
So let's leave it as-is.