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.