Re: __builtin_memcpy behavior
Toke Høiland-Jørgensen
"Tristan Mayfield" <mayfieldtristan@...> writes:
I'm not sure where the memory it was reading was and if that should bebpf_probe_read() will happily read any piece of kernel memory, it doesn't respect kernel boundaries. So if the call succeeded (you did check the return code, right?), that just means that the memory it was reading contained *something*, not that it was actually what you were *expecting* it to be. Should __builtin_memcpy be used? Or should bpf_probe_read? IfIn this case, I think what you're after is the BPF CO-RE facility in general. Have a look at Andrii's excellent introduction post here: https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html But basically, what it means is that if you add a magic attribute (preserve_access_index) to your variables, libbpf will notice that and perform load-time relocations so you get the right offset on the kernel you're running on. You can do this with your self-defined struct, but with BTF you don't even have to do that: You can make bpftool spit out a header file with all the structs defined by the current kernel and just include that (the struct name in this case would be 'struct trace_event_raw_tcp_event_sk_skb'). To do this, issue: bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h and use that as an include file. bpftool will even add a nice pragma statement at the top of the file so that all structs defined in it will automatically get the preserve_access_index attribute; which means you can basically use them like regular struct members (i.e., you can stick with __builtin_memcpy() and regular assignments) and still get the magic CO-RE relocations on load. Note that all this requires that your libbpf and clang versions are recent enough to understand all this, and libbpf will need the kernel BTF information to be present at load time (check for the existence of /sys/kernel/btf/vmlinux on the target system). -Toke
|
|