netdev - Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory accounting

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 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]

Date:   Sat, 5 Dec 2020 01:37:14 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Roman Gushchin <guro@...com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory
 accounting

On 12/3/20 4:26 AM, Roman Gushchin wrote:
> On Wed, Dec 02, 2020 at 06:54:46PM -0800, Alexei Starovoitov wrote:
>> On Tue, Dec 1, 2020 at 1:59 PM Roman Gushchin <guro@...com> wrote:
>>>
>>> 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had
>>>     a function to "explain" this case for users.
>> ...
>>> v9:
>>>    - always charge the saved memory cgroup, by Daniel, Toke and Alexei
>>>    - added bpf_map_kzalloc()
>>>    - rebase and minor fixes
>>
>> This looks great. Applied.
> 
> Thanks!
> 
>> Please follow up with a change to libbpf's pr_perm_msg().
>> That helpful warning should stay for old kernels, but it would be
>> misleading for new kernels.
>> libbpf probably needs a feature check to make this warning conditional.
> 
> I think we've discussed it several months ago and at that time we didn't
> find a good way to check this feature. I'll think again, but if somebody
> has any ideas here, I'll appreciate a lot.

Hm, bit tricky, agree .. given we only throw the warning in pr_perm_msg() for
non-root and thus probing options are also limited, otherwise just probing for
a helper that was added in this same cycle would have been good enough as a
simple heuristic. I wonder if it would make sense to add some hint inside the
bpf_{prog,map}_show_fdinfo() to indicate that accounting with memcg is enabled
for the prog/map one way or another? Not just for the sake of pr_perm_msg(), but
in general for apps to stop messing with rlimit at this point. Maybe also bpftool
feature probe could be extended to indicate that as well (e.g. the json output
can be fed into Go natively).