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

On Tue, 6 Mar 2018 15:42:41 -0800 Chris Mason wrote: > On 6 Mar 2018, at 11:12, Linus Torvalds wrote: > [...] > > > > I do *not* want this to be a magical way to hide things. > > Especially early on, this makes a lot of sense. But I wanted to plug > bps and the hopefully

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

On Thu, Mar 22, 2018 at 3:15 PM, Andy Lutomirski wrote: > All we need to do is to make sure that, if this is > distributed as a module, that it's init routine doesn't wait for a > long time, right? Yeap. Luis

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

On 3/22/18 3:15 PM, Andy Lutomirski wrote: On Thu, Mar 22, 2018 at 8:54 PM, Luis R. Rodriguez wrote: If we can ensure that these usermode modules don't take *any time at all* on their init *from the start*, it would be wonderful and we'd end up avoiding some really odd

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

On Thu, Mar 22, 2018 at 8:54 PM, Luis R. Rodriguez wrote: > If we can ensure that these usermode modules don't take *any time at all* on > their init *from the start*, it would be wonderful and we'd end up avoiding > some really odd corner case issues later. > I don't see why

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

On Sat, Mar 10, 2018 at 03:16:52PM +, Luis R. Rodriguez wrote: > On Sat, Mar 10, 2018 at 02:08:43PM +, Luis R. Rodriguez wrote: > > The alternative to this would be a simple equivalent of > > try_then_request_module() > > for UMH modules: try_umhm_then_request_umh_module() or whatever. So

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

On Mon, Mar 12, 2018 at 10:22:00AM -0700, Alexei Starovoitov wrote: > On 3/10/18 7:34 AM, Luis R. Rodriguez wrote: > > Also, > > > > Alexei you never answered my questions out aliases with the umh modules. > > Long term this important to consider. > > aliases always felt like a crutch to me. > I

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

On 3/12/18 5:02 AM, Edward Cree wrote: On 09/03/18 18:58, Alexei Starovoitov wrote: It's not waiting for the whole thing, because once bpfilter starts it stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state

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

On 3/10/18 7:34 AM, Luis R. Rodriguez wrote: Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. aliases always felt like a crutch to me. I can see an argument when they're used as 'alias pci:* foo' but the way it's used in

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

On 09/03/18 18:58, Alexei Starovoitov wrote: > It's not waiting for the whole thing, because once bpfilter starts it > stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state goes away. Does that mean your

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

On Sat, Mar 10, 2018 at 02:08:43PM +, Luis R. Rodriguez wrote: > The alternative to this would be a simple equivalent of > try_then_request_module() > for UMH modules: try_umhm_then_request_umh_module() or whatever. So just as I > argued earlier over UMH limitations, this is not the end of

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

Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. Luis

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

On Sat, Mar 10, 2018 at 1:43 AM, Alexei Starovoitov wrote: > On 3/9/18 11:37 AM, Andy Lutomirski wrote: >> >> On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: >>> >>> From: Alexei Starovoitov >>> Date: Fri, 9 Mar 2018 10:50:49 -0800 >>> On

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

On Fri, Mar 09, 2018 at 06:34:18PM -0800, Alexei Starovoitov wrote: > On 3/9/18 11:38 AM, Linus Torvalds wrote: > > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds > > wrote: > > > > > > How are you going to handle five processes doing the same setup > > >

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

On 3/9/18 11:38 AM, Linus Torvalds wrote: On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds wrote: How are you going to handle five processes doing the same setup concurrently? Side note: it's not just serialization. It's also "is it actually up and running".

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

On 3/9/18 11:37 AM, Andy Lutomirski wrote: On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: From: Alexei Starovoitov Date: Fri, 9 Mar 2018 10:50:49 -0800 On 3/9/18 10:23 AM, Andy Lutomirski wrote: It might not be totally crazy to back it by tmpfs.

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

On Fri, Mar 9, 2018 at 7:38 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds > wrote: >> >> How are you going to handle five processes doing the same setup concurrently? > > Side note: it's not just

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

On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Fri, 9 Mar 2018 10:50:49 -0800 > >> On 3/9/18 10:23 AM, Andy Lutomirski wrote: >>> It might not be totally crazy to back it by tmpfs. >> >> interesting. how do you propose to

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

On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds wrote: > > How are you going to handle five processes doing the same setup concurrently? Side note: it's not just serialization. It's also "is it actually up and running". The rule for "request_module()" (for a real

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

On Fri, Mar 9, 2018 at 10:57 AM, David Miller wrote: > > Once the helper UMH is invoked, it runs asynchronously taking eBPF > translation requests. How? Really. See my comment about mutual exclusion. The current patch is *broken* because it doesn't handle it. Really. Think

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

On 3/9/18 10:50 AM, Linus Torvalds wrote: On Fri, Mar 9, 2018 at 10:43 AM, Kees Cook wrote: Module loading (via kernel_read_file()) already uses deny_write_access(), and so does do_open_execat(). As long as module loading doesn't call allow_write_access() before the

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

From: Linus Torvalds Date: Fri, 9 Mar 2018 10:53:45 -0800 > Anyway, see my other suggestion that makes this all irrelevant. Just > wait synchronously (until the exit), and just use deny_write_access(). What exit? Once the helper UMH is invoked, it runs

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

From: Alexei Starovoitov Date: Fri, 9 Mar 2018 10:50:49 -0800 > On 3/9/18 10:23 AM, Andy Lutomirski wrote: >> It might not be totally crazy to back it by tmpfs. > > interesting. how do you propose to do it? > Something like: > - create /umh_module_tempxxx dir > - mount tmpfs there

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

On Fri, Mar 9, 2018 at 10:50 AM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 10:43 AM, Kees Cook wrote: >> >> Module loading (via kernel_read_file()) already uses >> deny_write_access(), and so does do_open_execat(). As long as module >>

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

On Fri, Mar 9, 2018 at 10:48 AM, Andy Lutomirski wrote: >> On Mar 9, 2018, at 10:17 AM, Linus Torvalds >> wrote: >> >> Hmm. I wish we had an "execute blob" model, but we really don't, and >> it would be hard/impossible to do without pinning

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

On 3/9/18 10:23 AM, Andy Lutomirski wrote: On Mar 9, 2018, at 10:15 AM, Greg KH wrote: Oh, and for the record, I like Andy's proposal as well as dumping this into a kernel module "blob" with the exception that this now would take up unswapable memory, which

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

On Fri, Mar 9, 2018 at 10:43 AM, Kees Cook wrote: > > Module loading (via kernel_read_file()) already uses > deny_write_access(), and so does do_open_execat(). As long as module > loading doesn't call allow_write_access() before the execve() has > started in the new

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

> On Mar 9, 2018, at 10:17 AM, Linus Torvalds > wrote: > > > Hmm. I wish we had an "execute blob" model, but we really don't, and > it would be hard/impossible to do without pinning the pages in memory. > Why so hard? We can already execute a struct file

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

On Fri, Mar 9, 2018 at 10:35 AM, David Miller wrote: > From: Linus Torvalds > Date: Fri, 9 Mar 2018 10:17:42 -0800 > >> - use deny_write_access() to make sure that we don't have active >> writers and cannot get them during the execve. > > I

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

From: Linus Torvalds Date: Fri, 9 Mar 2018 10:17:42 -0800 > - use deny_write_access() to make sure that we don't have active > writers and cannot get them during the execve. I agree that this is necessary for image validation purposes.

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

On Fri, Mar 09, 2018 at 10:23:27AM -0800, Andy Lutomirski wrote: > > > > On Mar 9, 2018, at 10:15 AM, Greg KH wrote: > > > > > > > Oh, and for the record, I like Andy's proposal as well as dumping this > > into a kernel module "blob" with the exception that this

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

> On Mar 9, 2018, at 10:15 AM, Greg KH wrote: > > > Oh, and for the record, I like Andy's proposal as well as dumping this > into a kernel module "blob" with the exception that this now would take > up unswapable memory, which isn't the nicest and is one big

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

On Thu, Mar 8, 2018 at 9:08 PM, Alexei Starovoitov wrote: > > there is not abi breakage and file cannot disappear from running task. > One cannot umount fs while file is still being used. I think that "cannot umount" part _is_ the ABI breakage that Andy is talking about. > Not only

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

On Fri, Mar 09, 2018 at 09:32:36AM -0800, Alexei Starovoitov wrote: > On 3/9/18 8:24 AM, Andy Lutomirski wrote: > > On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov wrote: > > > On 3/9/18 7:16 AM, Andy Lutomirski wrote: > > > > > > > > > > > > On Mar 8, 2018, at 9:08 PM, Alexei

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

On 3/9/18 8:24 AM, Andy Lutomirski wrote: On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov wrote: On 3/9/18 7:16 AM, Andy Lutomirski wrote: On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov wrote: On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8, 2018, at

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

On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov wrote: > On 3/9/18 7:16 AM, Andy Lutomirski wrote: On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov wrote: On 3/8/18 7:54 PM, Andy Lutomirski wrote: > On Mar 8, 2018, at 7:06 PM,

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

On 3/9/18 7:16 AM, Andy Lutomirski wrote: On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov wrote: On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8, 2018, at 7:06 PM, Linus Torvalds wrote: Honestly, that "read twice" thing may be what scuttles

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

>> On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov wrote: >> >> On 3/8/18 7:54 PM, Andy Lutomirski wrote: >> >> >> >>> On Mar 8, 2018, at 7:06 PM, Linus Torvalds >>> wrote: >>> >>> >>> Honestly, that "read twice" thing may be what scuttles this. >>>

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

On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8, 2018, at 7:06 PM, Linus Torvalds wrote: Honestly, that "read twice" thing may be what scuttles this. Initially, I thought it was a non-issue, because anybody who controls the module subdirectory enough to

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

> On Mar 8, 2018, at 7:06 PM, Linus Torvalds > wrote: > > > Honestly, that "read twice" thing may be what scuttles this. > Initially, I thought it was a non-issue, because anybody who controls > the module subdirectory enough to rewrite files would be in a

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

On Fri, Mar 09, 2018 at 02:12:24AM +, Andy Lutomirski wrote: > On Fri, Mar 9, 2018 at 1:20 AM, Alexei Starovoitov > wrote: > > On Fri, Mar 09, 2018 at 12:59:36AM +, Andy Lutomirski wrote: > >> > >> Alexei, can you give an example use case? I'm sure it's

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

On Thu, Mar 8, 2018 at 7:06 PM, Linus Torvalds wrote: > > So I don't like Andy's "let's make it a kernel module and then that > kernel module can execve() a blob". THAT seems like just stupid > indirection. > > But I do like Andy's "execve a blob" part, because it

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

> On Mar 8, 2018, at 6:31 PM, David Miller wrote: > > From: Andy Lutomirski > Date: Fri, 9 Mar 2018 02:12:24 + > >> First, compile your user code and emit a staitc binary. Use objdump >> fiddling or a trivial .S file to make that static binary into

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

On Thu, Mar 8, 2018 at 5:44 PM, Kees Cook wrote: > > My concerns are mostly about crossing namespaces. If a container > triggers an autoload, the result runs in the init_ns. Heh. I saw that as an advantage. It's basically the same semantics as a normal module load does -

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

From: Andy Lutomirski Date: Fri, 9 Mar 2018 02:12:24 + > 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

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

On Fri, Mar 9, 2018 at 1:20 AM, Alexei Starovoitov wrote: > On Fri, Mar 09, 2018 at 12:59:36AM +, Andy Lutomirski wrote: >> >> Alexei, can you give an example use case? I'm sure it's upthread >> somewhere, but I'm having trouble finding it. > > at the time of

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

On Thu, Mar 08, 2018 at 03:07:01PM -0800, Alexei Starovoitov wrote: > On 3/7/18 5:23 PM, Luis R. Rodriguez wrote: > > > > request_module() has its own world though too. How often in your proof of > > concept is request_module() called? How many times do you envision it being > > called? > >

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

On Thu, Mar 8, 2018 at 5:38 PM, Linus Torvalds wrote: > On Thu, Mar 8, 2018 at 4:59 PM, Andy Lutomirski wrote: >> >> Also, I don't see how this is any more exploitable than any other >> init_module(). > > Absolutely. If Kees doesn't trust the

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

On Thu, Mar 8, 2018 at 4:59 PM, Andy Lutomirski wrote: > > Also, I don't see how this is any more exploitable than any other > init_module(). Absolutely. If Kees doesn't trust the files to be loaded, an executable - even if it's running with root privileges and in the initns

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

On Fri, Mar 09, 2018 at 01:04:39AM +, Andy Lutomirski wrote: > On Fri, Mar 9, 2018 at 12:57 AM, Alexei Starovoitov wrote: > > On 3/8/18 4:24 PM, Kees Cook wrote: > >> > >> As Andy asked earlier, why not DYN too to catch PIE executables? Seems > >> like forcing the userspace

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

On Thu, Mar 8, 2018 at 4:57 PM, Alexei Starovoitov wrote: > The above are three paragraphs of security paranoia without single > concrete example of a security issue. How is running an arbitrary ELF as full init_ns root from a container not a concrete example? I'm not saying this

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

On Fri, Mar 09, 2018 at 12:59:36AM +, Andy Lutomirski wrote: > > Alexei, can you give an example use case? I'm sure it's upthread > somewhere, but I'm having trouble finding it. at the time of iptable's setsockopt() the kernel will do err = request_module("bpfilter"); once. The rough POC

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

On Fri, Mar 9, 2018 at 12:57 AM, Alexei Starovoitov wrote: > On 3/8/18 4:24 PM, Kees Cook wrote: >> >> As Andy asked earlier, why not DYN too to catch PIE executables? Seems >> like forcing the userspace helper to be non-PIE would defeat some of >> the userspace defenses in use in

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

On Fri, Mar 9, 2018 at 12:24 AM, Kees Cook wrote: > How is this not marked [RFC]? :) > > On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: >> As the first step in development of bpfilter project [1] the request_module() >> code is extended to allow

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

On 3/8/18 4:24 PM, Kees Cook wrote: How is this not marked [RFC]? :) On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: As the first step in development of bpfilter project [1] the request_module() code is extended to allow user mode helpers to be invoked. Idea is that

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

How is this not marked [RFC]? :) On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] the request_module() > code is extended to allow user mode helpers to be invoked. Idea is that > user mode helpers are built as

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

On 3/7/18 5:23 PM, Luis R. Rodriguez wrote: request_module() has its own world though too. How often in your proof of concept is request_module() called? How many times do you envision it being called? once. +static int run_umh(struct file *file) +{ + struct subprocess_info *sub_info

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

On Mon, Mar 05, 2018 at 05:34:57PM -0800, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] So meta :) The URL refers an lwn article, which in turn refers to this effort's first RFC. As someone only getting *one* of these patches in emails, It would be useful

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

From: Alexei Starovoitov Date: Mon, 5 Mar 2018 17:34:57 -0800 > As the first step in development of bpfilter project [1] the > request_module() code is extended to allow user mode helpers to be > invoked. Looks like there is a little bit of feedback requiring changes, please

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

On Tue, Mar 06, 2018 at 05:07:45PM -0800, Alexei Starovoitov wrote: > combining multiple answers... > > On 3/6/18 3:05 AM, Greg KH wrote: > > > > Any chance you can add a field to your "umh module" type such that a > > normal 'modinfo' program will be able to notice it is different easily? > >

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

combining multiple answers... On 3/6/18 3:05 AM, Greg KH wrote: Any chance you can add a field to your "umh module" type such that a normal 'modinfo' program will be able to notice it is different easily? ok. handling of modinfo turned out to be straightforward. kmod tooling worked fine with

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

On 6 Mar 2018, at 11:12, Linus Torvalds wrote: On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: As the first step in development of bpfilter project [1] the request_module() code is extended to allow user mode helpers to be invoked. Idea is that user mode helpers

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

On Tue, Mar 6, 2018 at 12:01 PM, Andy Lutomirski wrote: > > I assume I'm missing some context here, but why does this need to be > handled by the kernel rather than, say, a change to how modprobe > works? Honestly, the less we have to mess with user-mode tooling, the better.

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

On Tue, Mar 6, 2018 at 1:34 AM, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] the request_module() > code is extended to allow user mode helpers to be invoked. Idea is that > user mode helpers are built as part of the kernel build and

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

On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] the request_module() > code is extended to allow user mode helpers to be invoked. Idea is that > user mode helpers are built as part of the kernel build and

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

On Mon, Mar 05, 2018 at 05:34:57PM -0800, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] the request_module() > code is extended to allow user mode helpers to be invoked. Idea is that > user mode helpers are built as part of the kernel build and installed as >

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

On 3/5/18 6:13 PM, Randy Dunlap wrote: Hi, On 03/05/2018 05:34 PM, Alexei Starovoitov wrote: diff --git a/kernel/module.c b/kernel/module.c index ad2d420024f6..6cfa35795741 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3669,6 +3683,17 @@ static int load_module(struct load_info

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

Hi, On 03/05/2018 05:34 PM, Alexei Starovoitov wrote: > diff --git a/kernel/module.c b/kernel/module.c > index ad2d420024f6..6cfa35795741 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3669,6 +3683,17 @@ static int load_module(struct load_info *info, const > char __user *uargs, >