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?
>
> You said
>
> What you're saying is tomoyo doesn't trust kernel modules that are built-in
> as part of vmlinux and doesn't trust vmlinux build.
>
> but the word 'trust' has multiple aspects. One of aspects is "can the program
> contain malicious code?" which would be mitigated by cryptographic signing
usermode_blob is either part of kernel module or part of vmlinux.
If it's part of vmlinux it's inherently trusted.
If it's part of ko it's signed along with the rest of ko.
> We might need to invent built-in "protected userspace" because existing
> "unprotected userspace" is not trustworthy enough to run kernel modules.
> That's not just inventing fork_usermode_blob().
sorry, but this makes no sense at all to me.
> 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.
Currently we have the following:
vmlinux {
core code of kernel
built-in mod_A {
kernel code
}
built-in mod_B {
kernel code
}
}
loadable mod_C {
kernel code
}
With fork_usermode_blob() kernel modules can delegate parts of their
functionality to run in user space:
vmlinux {
core code of kernel
built-in mod_A {
kernel code
code to run in user space
}
built-in mod_B {
kernel code
code to run in user space
}
}
loadable mod_C {
kernel code
code to run in user space
}
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.
Take bpfilter, for example. It has its own format of structures
that are being passed between kernel side of bpfilter and user side
of bpfilter. It's bpfilter's internal interface that doesn't
create user api. bpfilter in kernel 5.x could be passing different
structs vs bpfilter in kernel 6.x.
It also cannot be started via init=, but it has to be ready
if pid 1 needs it.
Say, bpfilter was compiled as loadable kernel module.
In such case bpfilter.ko will not be loaded into the kernel
until the first iptables sockopt. It may never be loaded.
But when loaded the bpfilter.ko will start its user space side
via fork_usermode_blob() that is specific to that version of .ko.
Other kernel modules like bpf_lsm.ko will decide what's appropriate
for them in terms of when user side should start and exit.
Likely bpf_lsm.ko would want to be built-in.
In all cases kernel module cannot rely on traditional usermode_helper,
because usermode_helper is true uapi. The admin can boot kernel 5.x
and it must work with usermode_helpers installed in rootfs. The admin
will reboot to kernel 6.x and it should still work without changing rootfs.
Whereas usermode_blobs are ko and kernel specific.
