On Fri, 2004-12-31 at 10:39, Thomas Graf wrote:
> * jamal <1104505142.1048.262.camel@xxxxxxxxxxxxxxxx> 2004-12-31 09:59
> Exactly so we don't need any PIDs stored. /etc/iproute2/tc_matches.
Sure - that would be a fine place to store the IDs. Although i am not
sure you want to call it matches - rather its u32 program identifiers.
> > > __u8 kind; /* match type, for lookup in matchers table */
> >
> > 255 possible matchers max?
>
> 256 not enough?
I dont know, possible given how easy it would be to add a new match
that it wont be sufficient.
> > > __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.
>
We may be talking about different things - please double check.
The misunderstanding seems to be on scoping: PID is global and
the opaque ID is per match.
IOW, theres a hierachy:
A program(such as tc) installs a filter rule - we need to be able to
identify the program - this is the PID. Unique across all Linux.
A filter rule constitutes one or more matches. Different programs may
install different u32 rules. For most users its a single program - tc.
Each program that installs a rule will need to be identified by the PID.
Main purpose is so that it can decode what the second level number
means. This second level number is what i said was opaque. Its meaning
is per app.
So as an example PID 0x10 identifies application tc and opaque code
0x20 for tc translates to mean "thats an ip match, so no need to dump
raw data - just dump it in english using ip_print()".
0x10 belongs to the selector; 0x20 is per match. 0x21 could mean "this
is a TCP match with options" etc
The ematches on the hand are purely decodable via user space without
needing the opaque numbers - the kind/type serves these just fine.
> > 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.
the 16 bits for match handle sounds a little too generous; still 4 bits
or so from there should be fine.
> SEL2:
>
> TLV (TCA_U32_SEL2)
> +-------------------+
> | Selector header |
> +-------------------+
> | Match 1 TLV |
> +-------------------+
> | ... |
> +-------------------+
> | Match N TLV |
> +-------------------+
nod.
> 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)
nod.
> 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.
>
So essentiall good old u32 here?
> 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
> - ...
Everything is almost the same as to what i was saying - except i see the
u32 again there; isnt kind = 0 covering this?
> In case SEL1 TLV is provided we simply create a flat
> index with no containers and all AND relations.
No choice there.
> 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?
>
Ok, I may have understood what you are talking about in the second u32
where kind !=0.
I think we are in sync. Go nuts.
> > 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.
Its a non-trivial problem. Its ok to defer it for now but keep it in the
back of your mind.
cheers,
jamal
|