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 <>
To:     Roman Gushchin <>,
        Alexei Starovoitov <>
Cc:     bpf <>, Alexei Starovoitov <>,
        Network Development <>,
        Andrii Nakryiko <>,
        Andrew Morton <>,
        linux-mm <>,
        LKML <>,
        Kernel Team <>
Subject: Re: [PATCH bpf-next v9 00/34] bpf: switch to memcg-based memory

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 <> 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).

Powered by blists - more mailing lists