Linux 2.6 support for "rope" match module

Linux 2.6 support for "rope" match module

[Chris Lowth]

Following on from my message to this list of a month or so ago.. "rope" 
now works on linux 2.6 as well as 2.4. As yet SMP is not supported, but 
that is the next thing on my "to do" list, and should surface within a 
couple of months (time permitting).

Please feel free to download, play, comment / critique.

"rope" provides a kernel-level interpreter for a simple scripting 
language which can be used to develop netfilter match modules. The 
language is pre-compiled using a perl script, to produce a binary file 
that is loaded into the kernel using the "iptables" command. The 
language has access to many IP, TCP and UDP packet headers and the data 
payload. It was originally developed for use as a P2P protocol 
identification mechanism, but has wound up being general enough for 
wider use.

It's too large to supply here as a patch, but it can be downloaded from 
http://www.lowth.com/rope/Download. The "Makefile" that comes with the 
software allows rope to patched into POMNG, or directly into the kernel 
and iptables.

As before .. the website www.lowth.com/rope includes a number of sample 
scripts, language documentation and tutorials - etc.

Re: Linux 2.6 support for "rope" match module

[Jan Engelhardt]

> Please feel free to download, play, comment / critique.
>
> "rope" provides a kernel-level interpreter for a simple scripting language
> which can be used to develop netfilter match modules. The language is
> pre-compiled using a perl script, to produce a binary file that is loaded into
> the kernel using the "iptables" command. The language has access to many IP,
> TCP and UDP packet headers and the data payload. It was originally developed
> for use as a P2P protocol identification mechanism, but has wound up being
> general enough for wider use.

That almost feels like doing floating-point in kernelspace.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: Linux 2.6 support for "rope" match module

[Chris Lowth]

Jan Engelhardt wrote

>
>That almost feels like doing floating-point in kernelspace.
>
>  
>
In what sense?

Re: Linux 2.6 support for "rope" match module

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On Thu, Jan 05, 2006 at 11:07:53AM +0000, Chris Lowth wrote:
> Jan Engelhardt wrote
> 
> >That almost feels like doing floating-point in kernelspace.
> > 
> In what sense?

Chris, see, you might be new to this, so I give you some hints:

A number of people (in)frequently attempt to do a couple of things that
just ring all the alarm bells of kernel hackers.  Some of those are:

1) c++ in the kernel
2) bytecode interpreters (e.g. forth) in the kernel
3) floating point in the kernel

So while your rope module might solve your problems, you will have a
hard time finding anyone who thinks it is the right solution, and that
is independent of whatever the problem might be.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6 support for "rope" match module

[Chris Lowth]

Harald Welte wrote:

>Chris, see, you might be new to this, so I give you some hints:
>
>A number of people (in)frequently attempt to do a couple of things that
>just ring all the alarm bells of kernel hackers.  Some of those are:
>
>1) c++ in the kernel
>2) bytecode interpreters (e.g. forth) in the kernel
>3) floating point in the kernel
>
>  
>
Harald, thanks for taking the time comment.

Just to say: I have endeavoured to avoid the pitfalls associated with a 
general-purpose byte-code interpreter for the kernel. I rather see it as 
another point at which the kernel can be instructed to take actions 
through a user-process supplied structure - rather like routing tables, 
and netfilter itself - it's not really the equivalent of embedding a 
"forth" or "perl" interpreter into the kernel.

I have kept the rope module language very restricted in order to make it 
"kernel friendly". Hence...

1) it has no access to any system features or data except for the packet 
being matched and it's netfilter-related structures.
2) it has very limited string handling capability (no buffer copying is 
required by the vast majority of scripts) - so: no need for garbage 
collection etc. In fact I intended to strip out string buffer copying 
out entirely in a couple of releases time.
3) very limited script size - scripts are typically only a few lines in 
length.
4) tight restrictions on the number of times a loop can "spin" - so 
"while" loops etc cant cause blockages
5) enforced restrictions on the number of "actions" (instructions) a 
single script can perform.
6) no I/O is possible
7) no dynamic memory allocation required or allowed at run time.
8) my target is that a rope script exeucting 5 or more steps that are 
already available in other netfilter modules should be at least as fast 
as a netfilter chain containing those steps. The more "steps" used in 
the comparison - the better it gets. [though there is still scope for 
improvement in this arena].

Does this (in part, at least) address your concerns?

Chris