Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> On Fri, Nov 19, 2021 at 04:28:39PM +0100, Florian Westphal wrote:
> > Because the subtype is only 4 bits in size the exthdr
> > delinearization needs a fixup to remove the binop added by the
> > evaluation step.
>
> By the bitwise operation to take the 4 bits you can infer this refers to
> mptcp, but it might be good to store in the rule userdata area that this
> expression refers to mptcp as a suggestion to userspace when
> delinearizing the rule.
Why? Userspace has all info: its a tcp option, we have the tcp option
number (mptcp) and a 4 bit field which matches the template field.
There is no guesswork here.
Without this patch, we're asked to find a matching 1-byte field
(which does not exist).
Whats different vs. payload expressions here to require annotations?
> > One remaining usablility problem is the lack of mnemonics for the
> > subtype, i.e. something like:
> >
> > static const struct symbol_table mptcp_subtype_tbl = {
> > .base = BASE_DECIMAL,
> > .symbols = {
> > SYMBOL("mp-capable", 0),
> > SYMBOL("mp-join", 1),
> > SYMBOL("dss", 2),
> > SYMBOL("add-addr", 3),
> > SYMBOL("remove-addr", 4),
> > SYMBOL("mp-prio", 5),
> > SYMBOL("mp-fail", 6),
> > SYMBOL("mp-fastclose", 7),
> > SYMBOL("mp-tcprst", 8),
> > SYMBOL_LIST_END
> > },
> >
> > ... but this would need addition of yet another data type.
> >
> > Use of implicit/context-dependent symbol table would
> > be preferrable, I will look into this next.
>
> Could you develop your idea?
No idea, I have not thought about it at all. I do not want
to add a new data type for this.
One way is to just extend the scanner with even more keywords.
I tought I could annotate the eval context with 'saw mptcp'
and then use that when trying to resolve the symbol expressions.
No idea if that works and no idea how much hassle that is.
