On 3/15/22 4:14 PM, Yonghong Song wrote:
On 3/15/22 8:08 AM, Nikolay Borisov wrote:
On 15.03.22 г. 17:04 ч., Yonghong Song wrote:
On 3/15/22 4:09 AM, Nikolay Borisov wrote:
It would seem direct packet access is forbidden from SOCKET_FILTER programs, is this intentional ?
I.e I'm getting:
libbpf: prog 'socket_filter': BPF program load failed: Permission denied
libbpf: prog 'socket_filter': -- BEGIN PROG LOAD LOG --
0: R1=ctx(id=0,off=0,imm=0) R10=fp0
; int socket_filter(struct __sk_buff *skb)
0: (bf) r6 = r1 ; R1=ctx(id=0,off=0,imm=0) R6_w=ctx(id=0,off=0,imm=0)
1: (b7) r0 = 0 ; R0_w=inv0
; uint8_t *tail = (uint8_t *)(long)skb->data_end;
2: (61) r2 = *(u32 *)(r6 +80)
invalid bpf_context access off=80 size=4
processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
Yes, this is intentional. SOCKET_FILTER programs cannot access skb->data
and skb->data_end among other fields. See:
https://github.com/torvalds/linux/blob/master/net/core/filter.c#L7864-L7879
Right, my question is why is this the case? I don't see a reason why sk_filter_is_valid_access is not modified similarly to tc_cls_act_is_valid_access where data/data_end where the info->
reg_type = PTR_TO_PACKET(_END).
The sk_filter program is to mimic classic bpf which is used for
tcpdump. Daniel/Alexei should have more context why we don't
want to extend it.
It was not enabled given all the complexity that comes with spectre mitigations
and sock filter programs are typically used in unprivileged scenarios. It could
potentially be enabled iff the application has both cap_bpf + cap_perfmon permissions.
Cheers,
Daniel
