netdev - Re: [PATCH net-next] ebpf: move CONFIG_BPF_SYSCALL-only function declarations

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: <54F4A0DB.90004@iogearbox.net>
Date:	Mon, 02 Mar 2015 18:41:47 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Alexei Starovoitov <ast@...mgrid.com>
CC:	"David S. Miller" <davem@...emloft.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] ebpf: move CONFIG_BPF_SYSCALL-only function
 declarations

On 03/02/2015 06:35 PM, Alexei Starovoitov wrote:
> On Mon, Mar 2, 2015 at 6:21 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
>> Masami noted that it would be better to hide the remaining CONFIG_BPF_SYSCALL-only
>> function declarations within the BPF header ifdef, w/o else path dummy alternatives
>> since these functions are not supposed to have a user outside of CONFIG_BPF_SYSCALL.
>
> So far we didn't have anyone trying to add new map types
> outside of kernel/bpf/, so this patch is a defensive move.
> Such potential future abuser will get compile error for
> missing bpf_register_map_type() instead of linker error for the same.
> Not sure that's really needed.
> Also bpf_map_put() and bpf_map_get() are only used
> by bpf syscall and verifier. imo moving them under ifdef is overkill.
>
> I think ifdef should only be used for function that have
> real and dummy bodies.
> Today we have three:
> bpf_register_prog_type(), bpf_prog_get() and bpf_prog_put()
> and that makes sense.
>
> Hiding *map*() functions seems unnecessary.
> I think linker error is good enough.

I don't have a strong opinion here, we do similar hiding elsewhere,
e.g. in CONFIG_BPF_JIT. If it's for the sake that Masami can read the
code better, I'm okay with it, perhaps that will lead him to write
patches for eBPF code. ;)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html