netdev - Re: [PATCH v2] net: filter: Just In Time compiler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DAE8E47.7040409@redhat.com>
Date:	Wed, 20 Apr 2011 10:41:59 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Hagen Paul Pfeifer <hagen@...u.net>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [PATCH v2] net: filter: Just In Time compiler

On 04/14/2011 07:05 PM, Eric Dumazet wrote:
> Le jeudi 14 avril 2011 à 18:53 +0300, Avi Kivity a écrit :
>
> >  IMO, it will.  I'll try to have gcc optimize your example filter later.
>
> Sure you can JIT a C program from bpf. It should take maybe 30 minutes.
> It certainly is more easy than JIT an binary/assembly code :)
>
> Now take a look how I call slowpath, I am not sure gcc will actually
> generate better code because of C conventions.

Some things will be the same (like calling a function outside the jit).  
Some things will be faster.

> Loading a filter should be fast.
> Invoking a compiler is just too much work for BPF.
> Remember loading a filter is available to any user.

Like I mentioned before, use the interpreter until the result of the 
jitter is available.

> This idea would be good for netfilter stuff, because we dont load
> iptables rules that often.
>
> But still, the netfilter mainloop can be converted as a kernel JIT, most
> probably. All the complex stuff (matches, targets) must call external
> procedures anyway.

We could convert some matches to bytecode, probably.

To avoid getting into an infinite loop (btw, does you jit avoid infinite 
loops in the generated code?) I'll restate what I think are an external 
jit's advantages and then stop harping on the subject:

- less effort
- less kernel code
- better arch support
- better optimization
- better profiler/debugger integration
- multiple optimization levels (can use your jitter in userspace, or 
gcc, or llvm)

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html