Re: [PATCH nft,RFC,PoC 2/2] src: restore typeof datatype when listing set definition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 30, 2019 at 04:41:41PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > This is a proof-of-concept.
> > 
> > The idea behind this patch is to store the typeof definition
> > so it can be restored when listing it back.
> > 
> > Better way to do this would be to store the typeof expression
> > definition in a way that the set->key expression can be rebuilt.
> 
> Maybe we can store the raw netlink data that makes up the expression
> in the tlv area?

That's another possibility to explore.

> That would probably allow more code reuse to get back the "proper"
> type.

Just make sure there's sufficient context around to rebuild the
expression. Think of more complex fields that require bitmask
operations.

> One problem with my patch is that while you can add a map that
> returns "osf name", I could not find a way to easily re-lookup
> a suitable expression.  Storing a string would work of course,
> but I don't like it because we have no way to revalidate this.

I'm not advocating for storing the string. This was just a quick PoC
given the discussions after NFWS, and I wasn't sure everyone was on
the same page after it.

I agree with you in that the string is not the way to go.

> If we can reuse libnftnl/libmnl to have the basic netlink validation
> run on the blob we can at least be sure that its not complete garbage
> before we attempt to interpret the blob.

Please, go ahead explore that possibility. I'd try with payload
expressions, which are the most complex one. For thing like meta, it
should be simple to follow the approach you describe. Thanks.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux