netdev - Re: [PATCH v6 bpf-next 2/2] samples/bpf: sample application for eBPF load and socket creation split

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] [day] [month] [year] [list]

Date:   Thu, 3 Dec 2020 07:54:04 +0100
From:   Mariusz Dudek <mariusz.dudek@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Björn Töpel <bjorn.topel@...el.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        bpf <bpf@...r.kernel.org>,
        Mariusz Dudek <mariuszx.dudek@...el.com>
Subject: Re: [PATCH v6 bpf-next 2/2] samples/bpf: sample application for eBPF
 load and socket creation split

On Thu, Dec 3, 2020 at 3:50 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Wed, Dec 2, 2020 at 2:39 AM <mariusz.dudek@...il.com> wrote:
> >  int main(int argc, char **argv)
> >  {
> > +       struct __user_cap_header_struct hdr = { _LINUX_CAPABILITY_VERSION_3, 0 };
> > +       struct __user_cap_data_struct data[2] = { { 0 } };
> >         struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
> >         bool rx = false, tx = false;
> >         struct xsk_umem_info *umem;
> >         struct bpf_object *obj;
> > +       int xsks_map_fd = 0;
> >         pthread_t pt;
> >         int i, ret;
> >         void *bufs;
> >
> >         parse_command_line(argc, argv);
> >
> > -       if (setrlimit(RLIMIT_MEMLOCK, &r)) {
> > -               fprintf(stderr, "ERROR: setrlimit(RLIMIT_MEMLOCK) \"%s\"\n",
> > -                       strerror(errno));
> > -               exit(EXIT_FAILURE);
> > +       if (opt_reduced_cap) {
> > +               if (capget(&hdr, data)  < 0)
> > +                       fprintf(stderr, "Error getting capabilities\n");
> > +
> > +               data->effective &= CAP_TO_MASK(CAP_NET_RAW);
> > +               data->permitted &= CAP_TO_MASK(CAP_NET_RAW);
> > +
> > +               if (capset(&hdr, data) < 0)
> > +                       fprintf(stderr, "Setting capabilities failed\n");
> > +
> > +               if (capget(&hdr, data)  < 0) {
> > +                       fprintf(stderr, "Error getting capabilities\n");
> > +               } else {
> > +                       fprintf(stderr, "Capabilities EFF %x Caps INH %x Caps Per %x\n",
> > +                               data[0].effective, data[0].inheritable, data[0].permitted);
> > +                       fprintf(stderr, "Capabilities EFF %x Caps INH %x Caps Per %x\n",
> > +                               data[1].effective, data[1].inheritable, data[1].permitted);
> > +               }
> > +       } else {
> > +               if (setrlimit(RLIMIT_MEMLOCK, &r)) {
> > +                       fprintf(stderr, "ERROR: setrlimit(RLIMIT_MEMLOCK) \"%s\"\n",
> > +                               strerror(errno));
> > +                       exit(EXIT_FAILURE);
> > +               }
>
> Due to this hunk the patch had an unpleasant conflict with Roman's set
> and I had to drop this set from bpf-next.
> Please rebase and resend.
>
> But it made me look into this change...why did you make rlimit conditional here?
> That doesn't look right.

RLIMIT_MEMLOCK was conditioned before, so I didn't change it. It is
not in my branch "if (opt_reduced_cap)" because RLIMIT_MEMLOCK
requires additional CAP_IPC_LOCK and my main task was to made it
possible to use xsk_socket creation and this example with only
CAP_NET_RAW.

As described in the cover letter "In case your umem is larger or equal
process limit for MEMLOCK you need either increase the limit or
CAP_IPC_LOCK capability."