Re: bpf_fib_lookup support for firewall mark

[Rumen Telbizov <rumen.telbizov@menlosecurity.com>]

List,

For what it's worth I patched the structure locally by introducing a
new __u32 mark field
to the structure and adding the proper assignment of the field in
filter.c. Recompiled without any issues.
With that patch a bpf lookup matches ip rule that contains fwmark.

Still interested to know how much of a performance penalty adding an 4
bytes to the
structure brings. I'd certainly vote for adding at least the firewall
mark to the set of fields used in the lookup.

Cheers

On Wed, Jun 9, 2021 at 11:30 AM Rumen Telbizov
<rumen.telbizov@menlosecurity.com> wrote:
>
> Hi David,
>
> Thanks for the quick response. I appreciate it.
> A couple of quick follow up questions:
> 1. Do you have any performance data that would indicate how much of a
> performance drop adding an extra 4 or 8 bytes to the structure would
> cause?
> 2. If I patch locally the structure in libc and the kernel by adding
> an extra _u32 mark member is there anything that such a modification
> would break?
>
> Regards,
> Rumen Telbizov
>
>
> On Tue, Jun 8, 2021 at 6:21 PM David Ahern <dsahern@gmail.com> wrote:
> >
> > On 6/8/21 4:59 PM, Rumen Telbizov wrote:
> > > Dear BPF list,
> > >
> > > I am new to eBPF so go easy on me.
> > > It seems to me that currently eBPF has no support for route table
> > > lookups including firewall marks. The bpf_fib_lookup structure itself
> > > has no mark field as per
> > > https://elixir.bootlin.com/linux/v5.10.28/source/include/uapi/linux/bpf.h#L4864
> > >
> > > Additionally bpf_fib_lookup() function does not incorporate the
> > > firewall mark in its route lookup. It explicitly sets it to 0 as per
> > > https://elixir.bootlin.com/linux/v5.10.28/source/net/core/filter.c#L5329
> > > along with other fields which are used during the regular routing
> > > policy database lookup.
> > >
> > > Thus lookups from within eBPF and outside of it result in different
> > > outcomes if there are rules directing traffic based on fwmark.
> > > Can you please advise what the rationale for this is or if there
> > > anything that I might be missing.
> > >
> > > Let me know if I can provide any further information.
> > >
> >
> > The API (struct bpf_fib_lookup) is constrained to 64B for performance.
> > It is not possible to support all of the policy routing options that
> > Linux has in 64B. Choices had to be made.