bpf: Add probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers
mainline inclusion from mainline-v5.5-rc1 commit 6ae08ae3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4NI6R CVE: NA -------------------------------- The current bpf_probe_read() and bpf_probe_read_str() helpers are broken in that they assume they can be used for probing memory access for kernel space addresses /as well as/ user space addresses. However, plain use of probe_kernel_read() for both cases will attempt to always access kernel space address space given access is performed under KERNEL_DS and some archs in-fact have overlapping address spaces where a kernel pointer and user pointer would have the /same/ address value and therefore accessing application memory via bpf_probe_read{,_str}() would read garbage values. Lets fix BPF side by making use of recently added 3d708182 ("uaccess: Add non-pagefault user-space read functions"). Unfortunately, the only way to fix this status quo is to add dedicated bpf_probe_read_{user,kernel}() and bpf_probe_read_{user,kernel}_str() helpers. The bpf_probe_read{,_str}() helpers are kept as-is to retain their current behavior. The two *_user() variants attempt the access always under USER_DS set, the two *_kernel() variants will -EFAULT when accessing user memory if the underlying architecture has non-overlapping address ranges, also avoiding throwing the kernel warning via 00c42373 ("x86-64: add warning for non-canonical user access address dereferences"). Fixes: a5e8c070 ("bpf: add bpf_probe_read_str helper") Fixes: 2541517c ("tracing, perf: Implement BPF programs attached to kprobes") Signed-off-by:Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/796ee46e948bc808d54891a1108435f8652c6ca4.1572649915.git.daniel@iogearbox.net Conflicts: kernel/trace/bpf_trace.c Signed-off-by:
Pu Lehui <pulehui@huawei.com> Reviewed-by:
Kuohai Xu <xukuohai@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
Loading
Please sign in to comment