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

On Mar 8, 2018, at 6:31 PM, David Miller [off-list ref] wrote:

From: Andy Lutomirski <luto@kernel.org>
Date: Fri, 9 Mar 2018 02:12:24 +0000

quoted

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.

I don’t know what you mean.  Alexei’s approach introduces a whole new kind of special module.  Mine doesn’t. 

quoted

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.

How?  I think you’ll find that a non-modular implementation of a bundled ELF binary looks a *lot* like my call_umh_blob().

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.

I’m not making any arguments about security at all. I’m talking about functionality. 

If we apply Alexei’s patch as is, then I think we’ll have a situation where ET_EXEC modules are only useful if they can do their jobs without any filesystem access at all.  This is fine for networking, where netlink sockets are used, but I think it’s not so great for other use cases. If we ever try to stick a usb driver into userspace, we’re going to want to instantiate the user task once per device, passed as stdin or similar, and Alexei’s code will make that very awkward.