On 2020/06/13 12:38, Alexei Starovoitov wrote:
> On Fri, Jun 12, 2020 at 09:57:40AM +0900, Tetsuo Handa wrote:
>>
>> , the userspace memory can be easily interfered from userspace. The kernel module
>> running in kernel space is protected (unless methods like /dev/{mem,kmem} are used)
>> but the kernel module running in user space is not protected.
>
> huh? One user process 'can easily interfere' with memory of other process?
It is an execution environment problem.
Somebody can send SIGKILL (e.g. OOM-killker, SysRq-i) to kill kernel code running as
usermode process, somebody can send SIGSTOP to make kernel code running as usermode
process defunctional, somebody can /usr/bin/strace in order to eavesdrop on secret
data used by kernel code running as usermode process etc.
>> can be interfered) is so painful. I won't be able to trust kernel modules running
>> in userspace memory.
>
> The part that I suspect is still missing is what triggers fork_usermode_blob().
> It's always kernel code == trusted code.
How can that part be guaranteed?
In future somebody might add a caller that allows
sys_execute_anonymously_in_usermode(const char code, const int len) {
return fork_usermode_blob(code, len);
}
or something similar.
> The interface between kernel part of .ko and user part of .ko is
> specific to that particular kernel module. It's not a typical user space.
How can that part be guaranteed? A caller can pass arbitrary code including
typical user space program (e.g. /bin/sh).
> But when loaded the bpfilter.ko will start its user space side
> via fork_usermode_blob() that is specific to that version of .ko.
How can we guarantee that its user space side started via fork_usermode_blob()
is not disturbed (e.g. SIGKILL, SIGSTOP, /usr/bin/strace) ?
I consider that reliability (from "robustness" perspective) of fork_usermode_blob()
is same with CONFIG_INITRAMFS_SOURCE or call_usermodehelper() or init= approach.
