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:   Mon, 20 Jan 2020 23:31:28 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Alexei Starovoitov <ast@...nel.org>
CC:     "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 1/3] bpf: Introduce dynamic program extensions

On 1/20/20 2:52 PM, Andrii Nakryiko wrote:
>> +       }
>> +       if (tr->extension_prog) {
>> +               /* cannot attach fentry/fexit if extension prog is attached */
>> +               err = -EBUSY;
>> +               goto out;
>> +       }
> move this check before BPF_TRAMP_REPLACE check and check additonally
> for fentry+fexit for BPF_TRAMP_REPLACE? Nothing can replace
> extension_prog, right?

makes sense. fixed.

>> +               if (tgt_prog->type == BPF_PROG_TYPE_TRACING &&
>> +                   tgt_prog->expected_attach_type != BPF_TRACE_RAW_TP &&
> if the intent is to prevent extending FENTRY/FEXIT, why not checking
> explicitly for those two instead of making assumption that
> expected_attach_type can be only one of RAW_TP/FENTRY/FEXIT, this can
> easily change in the future. Besides, direct FENTRY/FEXIT comparison
> is more self-documenting as well.

sure. fixed as well.

>>                  }
>> +               if (prog_extension &&
>> +                   btf_check_type_match(env, prog, btf, t))
> this reads so weird... btf_check_type_match (and
> btf_check_func_type_match as well) are boolean functions (i.e., either
> matches or not, or some error), why not using a conventional
> boolean+error return convention: 0 - false, 1 - true, <0 - error
> (bug)?

I cannot agree here. Such return convention will be very odd.
The one I picked is consistent with other places.

Powered by blists - more mailing lists