netdev - Re: [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in all samples

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: <20201027081440.756cd175@carbon>
Date:   Tue, 27 Oct 2020 08:14:40 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     daniel@...earbox.net, ast@...com, bpf@...r.kernel.org,
        netdev@...r.kernel.org, brouer@...hat.com,
        Roman Gushchin <guro@...com>, kernel-team@...com
Subject: Re: [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in
 all samples

On Tue, 27 Oct 2020 00:36:23 +0100
Toke Høiland-Jørgensen <toke@...hat.com> wrote:

> The memlock rlimit is a notorious source of failure for BPF programs. Most
> of the samples just set it to infinity, but a few used a lower limit. The
> problem with unconditionally setting a lower limit is that this will also
> override the limit if the system-wide setting is *higher* than the limit
> being set, which can lead to failures on systems that lock a lot of memory,
> but set 'ulimit -l' to unlimited before running a sample.
> 
> One fix for this is to only conditionally set the limit if the current
> limit is lower, but it is simpler to just unify all the samples and have
> them all set the limit to infinity.
> 
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>

This change basically disable the memlock rlimit system. And this
disable method is becoming standard in more and more BPF programs.
IMHO using the system-wide memlock rlimit doesn't make sense for BPF.

I'm still ACKing the patch, as this seems the only way forward, to
ignore and in-practice not use the memlock rlimit.

Acked-by: Jesper Dangaard Brouer <brouer@...hat.com>

I saw some patches on the list (from Facebook) with a new system for
policy limiting memory usage per BPF program or was it mem-cgroup, but
I don't think that was ever merged... I would really like to see
something replace (and remove) this memlock rlimit dependency. Anyone
knows what happened to that effort?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer