linux-kernel - 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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEf4BzYe1SDnWBzAP_U7NtUhu_cWa0EEMLv+d-q3YTFvP+y3og@mail.gmail.com>
Date:   Mon, 7 Dec 2020 18:53:33 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Roman Gushchin <guro@...com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        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 Fri, Dec 4, 2020 at 4:37 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> 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

I think the initial version was emitting 0 for memlock, so that was a
pretty simple way to prove stuff. But I think it was changed at the
last minute to emit some non-zero "estimate" of memory used or
something like that?

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