Thread (68 messages) flat view 68 messages, 14 authors, 2018-05-02

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

From: David Miller <davem@davemloft.net>
Date: 2018-03-09 02:31:59
Also in: lkml, netdev

From: Andy Lutomirski <luto@kernel.org>
Date: Fri, 9 Mar 2018 02:12:24 +0000
First, compile your user code and emit a staitc binary.  Use objdump
fiddling or a trivial .S file to make that static binary into a
variable.  Then write a tiny shim module like this:

extern unsigned char __begin_user_code[], __end_user_code[];

int __init init_shim_module(void)
{
  return call_umh_blob(__begin_user_code, __end_user_code - __begin_user_code);
}

By itself, this is clearly a worse solution than yours, but it has two
benefits, one small and two big.  The small benefit is that it is
completely invisible to userspace: the .ko file is a bona fide module.
Anything you try to do which makes these binaries "special" is a huge
negative.
The big benefits are:
I don't see those things as benefits at all, and Alexei's scheme can
easily be made to work in your benefit #1 case too.

It's a user binary.  It's shipped with the kernel and it's signed.

If we can't trust that, we can't trust much else.

And this whole container argument..  It's a mirage.

Kernel modules are 1000 times worse, since they can access any
container and any namespace they want.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help