> On Mar 8, 2018, at 6:31 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
>
> From: Andy Lutomirski <luto@xxxxxxxxxx>
> 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.
I don’t know what you mean. Alexei’s approach introduces a whole new kind of special module. Mine doesn’t.
>
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
