On Thu, Jul 21, 2016 at 01:00:51AM +0200, Daniel Borkmann wrote:[...]
I don't really like couple of things, your ifdef CONFIG_MMU might not be* You're right about CONFIG_MMU. We don't need it, all of the nommu platforms
needed I think, couple of these checks seem redundant, (I'm not yet sure
about the task->mm != task->active_mm thingy), the helper should definitely
be gpl_only and ARG_PTR_TO_RAW_STACK is just buggy. Also, this should be
a bit analogue to bpf_probe_read we have. How about something roughly along
the lines of below diff (obviously needs extensive testing ...)? This
can still do all kind of ugly crap to the user process, but limited to
the cap_sys_admin to shoot himself in the foot.
properly deal with it from my research.
It was always ARG_PTR_TO_STACK? Or are you saying ARG_PTR_TO_STACK is buggy and
we should make it ARG_PTR_TO_RAW_STACK?
I originally named the function bpf_probe_write. Upon further thought I don't
think that makes sense. The reason is because bpf_probe_read is analogous to
probe_kernel_read. If we had bpf_probe_write, I think people might reason it to
be equivalent to probe_kernel_write, and be confused when they can't write to
kernel space.
I tried to make the external facing documentaion close to copy_to_user. That's
how people should use it, not like _write. Therefor I think it makes sense to
keep that the name.
I added a check for (!task) -- It seems to be spattered throughou the eBPF
helper code. Alexei mentioned earlier that it can be null, but I'm not sure of
the case
RE: task->mm != task->active_mm -- There are a couple scenarios where kthreads
do this, and the only user call that should hit this is execve. There's only a
brief period where this can be true and I don't think it's worth dealing with
that case -- I'm not really sure you can plant a kprobe at the right site either
Did some minimal testing with tracex7 and others.
I was able to copy memory into other process's space while certain
syscalls were going on. I don't think that there are a reasonable set of
protections.
I'll do more testing. Any suggestions of what might break? I've looked at
writing to unitialized memory, Memory out of bounds, etc... Do you know of any
"weak spots"?