On Fri, Feb 22, 2019 at 03:16:35PM -0800, Linus Torvalds wrote: > > So a kernel pointer value of 0x12345678 could be a value kernel > pointer pointing to some random kmalloc'ed kernel memory, and a user > pointer value of 0x12345678 could be a valid _user_ pointer pointing > to some user mapping. > > See? > > If you access a user pointer, you need to use a user accessor function > (eg "get_user()"), while if you access a kernel pointer you need to > just dereference it directly (unless you can't trust it, in which case > you need to use a _different_ accessor function).
that was clear already. Reading 0x12345678 via probe_kernel_read can return valid value and via get_user() can return another valid value on _some_ architectures. > The fact that user and kernel pointers happen to be distinct on x86-64 > (right now) is just a random implementation detail. yes and my point that people already rely on this implementation detail. Say we implement int bpf_probe_read(void *val, void *unsafe_ptr) { if (probe_kernel_read(val, unsafe_ptr) == OK) { return 0; } else (get_user(val, unsafe_ptr) == OK) { return 0; } else { *val = 0; return -EFAULT; } } It will preserve existing bpf_probe_read() behavior on x86. If x86 implementation changes tomorrow then progs that read user addresses may start failing randomly because first probe_kernel_read() will be returning random values from kernel memory and that's no good, but at least we won't be breaking them today, so we have time to introduce bpf_user_read and bpf_kernel_read and folks have time to adopt them. Imo that's much better than making current bpf_probe_read() fail on user addresses today and not providing a non disruptive path forward.