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
| ||
|
Date: Wed, 30 Sep 2020 09:58:10 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Martin KaFai Lau <kafai@...com> Cc: ast@...nel.org, john.fastabend@...il.com, netdev@...r.kernel.org, bpf@...r.kernel.org, David Ahern <dsahern@...nel.org> Subject: Re: [PATCH bpf-next v3 3/6] bpf: add redirect_neigh helper as redirect drop-in On 9/30/20 8:48 AM, Martin KaFai Lau wrote: > On Tue, Sep 29, 2020 at 11:23:03PM +0200, Daniel Borkmann wrote: [...] > >> +/* Internal, non-exposed redirect flags. */ >> +enum { >> + BPF_F_NEIGH = (1ULL << 1), >> +}; > It will be useful to ensure the future "flags" of BPF_FUNC_redirect > will not overlap with this. May be a BUILD_BUG_ON? I was thinking about this as well, but didn't go for it since typically this would mean that we need to add a mask of all flags for redirect helper in uapi right next to where we define BPF_F_INGRESS such that people don't forget to update the mask whenever they extend the flags there in order for the BUILD_BUG_ON() assertion to be actually effective (see also RTAX_FEATURE_MASK vs DST_FEATURE_MASK). If the mask sits in a different location, then developers might forget to update, it might slip through review (since not included in diff) and the build failure doesn't trigger. So far we have avoided to extend bpf uapi in such way. That was basically my rationale, another option could be to just add a comment in the enum right underneath BPF_F_INGRESS that the (1ULL << 1) bit is currently kernel-internal. > Others LGTM. > > Acked-by: Martin KaFai Lau <kafai@...com> Thanks!
Powered by blists - more mailing lists