Re: [PATCH] bpf.2: Change note on unprivileged access

[Quentin Monnet <quentin@isovalent.com>]

2020-04-22 14:26 UTC+0200 ~ Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com>

[...]

> So, just to confirm my understanding, the current set of helpers
> permitted to unprivileged callers is:
> 
>     From sk_filter_func_proto():
>         bpf_skb_load_bytes_proto
>         bpf_skb_load_bytes_relative_proto
>         bpf_get_socket_cookie_proto
>         bpf_get_socket_uid_proto
>         bpf_skb_event_output_proto
>     From cg_skb_func_proto():
>         bpf_get_local_storage_proto
>         bpf_sk_fullsock_proto
>         bpf_sk_storage_get_proto
>         bpf_sk_storage_delete_proto
>         bpf_skb_event_output_proto
>         bpf_skb_cgroup_id_proto
>         bpf_tcp_sock_proto
>         bpf_get_listener_sock_proto
>         bpf_skb_ecn_set_ce_proto
>     From bpf_base_func_proto():
>         bpf_map_lookup_elem_proto
>         bpf_map_update_elem_proto
>         bpf_map_delete_elem_proto
>         bpf_map_push_elem_proto
>         bpf_map_pop_elem_proto
>         bpf_map_peek_elem_proto
>         bpf_get_prandom_u32_proto
>         bpf_get_raw_smp_processor_id_proto
>         bpf_get_numa_node_id_proto
>         bpf_tail_call_proto
>         bpf_ktime_get_ns_proto

Hi Michael,
Yes, this looks accurate at this time.

> I think that man-pages patches along the lines you mention
> would be a good start (although the references to kernel sources
> may be a bit fragile), so if you would be willing to write those,
> it would be great.
> 
> Just by the way, is it not possible to add notes to the text
> of each helper to say that it is usable by an unprivileged caller?
> I know this is also fragile, in the case of subsequent additions
> and changes, but it would make the user-space programmer's life
> a little easier (since they would not always be forced to look
> at the kernel source).

It would be possible of course, but I am convinced it would add to the
maintenance load and grow quickly out of sync. New helpers will be
added, some existing ones could be opened to unprivileged, and so on. I
would prefer to avoid that.

I agree that the note about kernel structs to check is fragile too, on a
second thought I will not send it for now.

What we could do instead is rely on bpftool. It is a utility for
introspection, management etc. of BPF objects (see
tools/bpf/bpftool/Documentation in kernel repo for more info). It is
able to probe and dump the list of supported BPF prog/map types and BPF
helper functions on the system, with "bpftool feature probe". This
feature probing is currently reserved for root, but simply because it
was easier to implement that way, and could probably be extended to
unprivileged.

So I would suggest we work to have bpftool dump the list of helpers for
non-root - I can add that to my to-do list -, and then add a note to the
manual page to mention it. Actually I can add the note already, since
admins may be interested in probing a given helper for availability.

What do you think?
Quentin