netdev - Re: [PATCH bpf-next v2] bpftool: Probe for memcg-based accounting before bumping rlimit

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: <Yrx7fFFOC0Emzorz@google.com>
Date:   Wed, 29 Jun 2022 09:19:08 -0700
From:   sdf@...gle.com
To:     Quentin Monnet <quentin@...valent.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH bpf-next v2] bpftool: Probe for memcg-based accounting
 before bumping rlimit

On 06/29, Quentin Monnet wrote:
> Bpftool used to bump the memlock rlimit to make sure to be able to load
> BPF objects. After the kernel has switched to memcg-based memory
> accounting [0] in 5.11, bpftool has relied on libbpf to probe the system
> for memcg-based accounting support and for raising the rlimit if
> necessary [1]. But this was later reverted, because the probe would
> sometimes fail, resulting in bpftool not being able to load all required
> objects [2].

> Here we add a more efficient probe, in bpftool itself. We first lower
> the rlimit to 0, then we attempt to load a BPF object (and finally reset
> the rlimit): if the load succeeds, then memcg-based memory accounting is
> supported.

> This approach was earlier proposed for the probe in libbpf itself [3],
> but given that the library may be used in multithreaded applications,
> the probe could have undesirable consequences if one thread attempts to
> lock kernel memory while memlock rlimit is at 0. Since bpftool is
> single-threaded and the rlimit is process-based, this is fine to do in
> bpftool itself.

> This probe was inspired by the similar one from the cilium/ebpf Go
> library [4].

> v2:
> - Simply use sizeof(attr) instead of hardcoding a size via
>    offsetofend().
> - Set r0 = 0 before returning in sample program.

> [0] commit 97306be45fbe ("Merge branch 'switch to memcg-based memory  
> accounting'")
> [1] commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of  
> RLIMIT_MEMLOCK")
> [2] commit 6b4384ff1088 ("Revert "bpftool: Use libbpf 1.0 API mode  
> instead of RLIMIT_MEMLOCK"")
> [3]  
> https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/t/#u
> [4] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39

> Cc: Stanislav Fomichev <sdf@...gle.com>

Reviewed-by: Stanislav Fomichev <sdf@...gle.com>