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
traditional kernel modules with .ko file extension into distro specified
loc
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,
>
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 *inf
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
>
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 installed as
> tradition
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 installed as
> tradition
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.
We've been *so* much
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 are built as part of
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
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?
>
> o
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
take care of that an
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 if
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 =
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 part of the kernel
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
user mode helpers
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 user mode helpers to be invoked. Idea is
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 most distros.
>
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 cod
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 approach can ne
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 helper to be non-PI
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 - is still fundamenta
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 files to be loaded, an
> executable - even if it's run
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?
>
> once.
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 iptable's setsockopt() the kernel
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 __begin_user_code[],
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 - in that the "kernel names
> 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 a
>> variable. Then write a tiny shim
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 is the *blob*
> that has had its
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 upthread
> >> somewhere, but I'm ha
> 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 position
> to just execute the file
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 rewrite files would be in a posi
>> 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.
>>> Initially, I thought it was a non-issue, becaus
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 this.
Initially, I thought it was a non-issu
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, Linus Torvalds
> 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 Starovoitov wrote:
On 3/8/18 7:54 PM, Andy Lutomirski wrote:
On Mar 8, 2018, at 7:06 PM, Linus Torvalds
wrote
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 Starovoitov wro
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 "read twice",
> 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 reason we
> removed the in-kernel-
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 now would take
> > up unswapab
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.
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 agree that this is necessary for image validation purpo
> 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 for execveat, and Alexei
already
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 implementation, I think we'd be
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 isn't the nicest and is one bi
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 the pages in memory.
>>
>
> Why so hard? We can alread
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
>> loading doesn't call allow_write_access() before the exe
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
> - copy elf i
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 asynchronously taking eBPF
translation req
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 execve() has
started in the
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 of it this way - you
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 module) has been that it
returns
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 do it?
>> Something like:
>> - crea
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 serialization. It's also "is it actually up
> and running".
>
I think
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.
interesting. how do you propose to do
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".
The rule for "request_module()" (
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
> > > concurrently?
Let's keep in mind we don
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 3/9/18 10:23 AM, Andy Lutomirski wrote:
>
>>
Also,
Alexei you never answered my questions out aliases with the umh modules.
Long term this important to consider.
Luis
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 the
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 iptables/net
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 netwo
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 goes
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
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
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 this issue needs to
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 corner case issues later.
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
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 growing set of bpf
68 matches
Mail list logo
