* jamal <1104505142.1048.262.camel@xxxxxxxxxxxxxxxx> 2004-12-31 09:59
> On Fri, 2004-12-31 at 06:08, Thomas Graf wrote:
> > * jamal <1104469111.1049.219.camel@xxxxxxxxxxxxxxxx> 2004-12-30 23:58
>
> > > perhaps we need a few bits in the selector to identify
> > > the owner who installed the rule to begin with. Then it would be safe to
> > > interpret the meaning of the ID (by the same app). Did you say there
> > > were some unused bits in the selector?
> >
> > Right, but why not do this in userspace by having a global map
> > somewhere in a file? A u32 config could have been modified by
> > multiple pids and it would get really messy to store a pid for
> > every possible changeable item.
>
> The "PID" is per app - same as it is for rtm where the different known
> routing apps like zebra are given an ID and certain IDs are left blank
> for general use. So if you run multiple tcs they will all have the same
> ID. The way the id is used in the rtm historically has been for allowing
> multiple route protocols to install route entries (this way for example
> OSPF does/nt announce RIP routes etc). In our case this would mean:
> "this rule was installed by tc - only it knows what the opaque value
> 10 means". In that case tc would be responsible to decode 10 which would
> mean to it "this is an ip match therefore use ip_print() to pretty
> print" and 10 is global to tc only and in that case stored in some
> header file belonging to tc.
Exactly so we don't need any PIDs stored. /etc/iproute2/tc_matches.
> > __u8 kind; /* match type, for lookup in matchers table */
>
> 255 possible matchers max?
256 not enough?
> > __u8 flags; /* Invert Flag + Relations */
> > __u16 handle; /* must be unique per selector, may be autogenerated */
>
> Ok this is the one used to store the opaque IDs - unique per app
> so may be the same across multiple selectors.
No, it must be unique, we will return EINVAL if it isn't. Most
apps will set it to 0 which will autogenerate it with a
generate && !get just like in u32.
> Probably steal a few bits from here and use them in nkind.
Fair, we can also steal a few bits from flags although I'd like to
keep at least 3 empty.
> Maybe i misunderstood you. You are going to have:
>
> SEL2
> |
> |
> +--match1
> | |
> | + -- extended match1
> . .
> . .
> . .
> . +---- extnded matchn
> |
> +--- matchn
>
>
> Why does the first one have to be speacial?
No, I'm going to have everything be ematches.
> One of the mistakes in u32 is the tight packing of the matches. ie the
> match1-n above are packet together. If they were put in TLVs probably
> only new thing that will be needed is MATCH2 TLV.
> No harm in transporting an extra 32 bits for a TLV - its not like you
> are going to have a million matches and need to save space.
> So i would suggest everything under a TLV (SEL2->MATCH(ES)->EMATCH(ES))
SEL2:
TLV (TCA_U32_SEL2)
+-------------------+
| Selector header |
+-------------------+
| Match 1 TLV |
+-------------------+
| ... |
+-------------------+
| Match N TLV |
+-------------------+
where Match TLV:
+--------------------+
| Match Header (u32) |
+- - - - - - - - - - +
| Match Data |
+--------------------+
Where Header:
u8 kind;
u8 flags;
u16 handle;
(or some more for kind and less for handle)
where
kind := { 0 | match type }
handle := { 0 | unique }
where kind == 0 means that the match is a container and data
contains a u32 pointing into the match array.
where kind != 0 means a match to be looked up in the matcher
ops table.
with the following matches:
- u32: {u8|u16|u32} at offset match
- meta
- kmp
- nbyte
- ...
In case SEL1 TLV is provided we simply create a flat
index with no containers and all AND relations.
Which means we can do:
Sel2
\__match u32 at 2 16 0xff
|
+ and match meta nfmark 2
|
+ and container
\__match u32 at 4 11 0xf0
|
+ or nbyte "::1" at 12
Thoughts?
> A virus would span several packets. So the state/knowldge of whether
> something is a virus is spread across several packets. That knowledge
> typically needs to be accumulated before making a call. Is this thing
> capable of remembering?
Not and I would rather do it outside in a separate ematch to match
stateful information. I have to think some more about this though.
|