* [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context
@ 2013-05-17 5:45 Eric Dumazet
2013-05-17 21:19 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2013-05-17 5:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Al Viro
From: Eric Dumazet <edumazet@google.com>
It looks like we can call module_free()/vfree() from softirq context,
so no longer need a wrapper and a work_struct.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
---
arch/x86/net/bpf_jit_comp.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index f66b540..c0212db 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -717,9 +717,7 @@ cond_branch: f_offset = addrs[i + filter[i].jf] - addrs[i];
break;
}
if (proglen == oldproglen) {
- image = module_alloc(max_t(unsigned int,
- proglen,
- sizeof(struct work_struct)));
+ image = module_alloc(proglen);
if (!image)
goto out;
}
@@ -738,20 +736,8 @@ out:
return;
}
-static void jit_free_defer(struct work_struct *arg)
-{
- module_free(NULL, arg);
-}
-
-/* run from softirq, we must use a work_struct to call
- * module_free() from process context
- */
void bpf_jit_free(struct sk_filter *fp)
{
- if (fp->bpf_func != sk_run_filter) {
- struct work_struct *work = (struct work_struct *)fp->bpf_func;
-
- INIT_WORK(work, jit_free_defer);
- schedule_work(work);
- }
+ if (fp->bpf_func != sk_run_filter)
+ module_free(NULL, fp->bpf_func);
}
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context
2013-05-17 5:45 [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context Eric Dumazet
@ 2013-05-17 21:19 ` David Miller
2013-05-17 22:22 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2013-05-17 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, viro
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 16 May 2013 22:45:30 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> It looks like we can call module_free()/vfree() from softirq context,
> so no longer need a wrapper and a work_struct.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context
2013-05-17 21:19 ` David Miller
@ 2013-05-17 22:22 ` Eric Dumazet
2013-05-18 1:29 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2013-05-17 22:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, viro
On Fri, 2013-05-17 at 14:19 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 16 May 2013 22:45:30 -0700
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > It looks like we can call module_free()/vfree() from softirq context,
> > so no longer need a wrapper and a work_struct.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Applied.
Thanks David
I am considering adding ReadOnly protection to the pages containing BPF
generated code, like we do for modules text if
CONFIG_DEBUG_SET_MODULE_RONX=y
Should we have an option to configure this, driven by HAVE_BPF_JIT_RO,
or should we do the RO thing in all cases (ie not adding yet another
Kconfig stuff)
Another ongoing work is to add some protection against BPF JIT spraying
attacks
( http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html )
My idea would be to have a hole of random size before the code, filled
with 0xcc (int3) opcodes. Since we allocate a multiple of PAGE_SIZE
anyway, we have plenty of available space to play with.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context
2013-05-17 22:22 ` Eric Dumazet
@ 2013-05-18 1:29 ` David Miller
0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2013-05-18 1:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, viro
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 17 May 2013 15:22:46 -0700
> I am considering adding ReadOnly protection to the pages containing BPF
> generated code, like we do for modules text if
> CONFIG_DEBUG_SET_MODULE_RONX=y
>
> Should we have an option to configure this, driven by HAVE_BPF_JIT_RO,
> or should we do the RO thing in all cases (ie not adding yet another
> Kconfig stuff)
I think we should do this unconditionally, it'll be noise as far as
overhead during filter compilation.
> Another ongoing work is to add some protection against BPF JIT spraying
> attacks
> ( http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html )
>
> My idea would be to have a hole of random size before the code, filled
> with 0xcc (int3) opcodes. Since we allocate a multiple of PAGE_SIZE
> anyway, we have plenty of available space to play with.
This sounds like a good idea too.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-05-18 1:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-17 5:45 [PATCH net-next] x86: bpf_jit_comp: can call module_free() from any context Eric Dumazet
2013-05-17 21:19 ` David Miller
2013-05-17 22:22 ` Eric Dumazet
2013-05-18 1:29 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox