Eugene Crosser <crosser@xxxxxxxxxxx> wrote:
> On 19/06/2020 17:15, Pablo Neira Ayuso wrote:
> >>>>> Why not make a patch to publicly expose the skb's data via nft_meta?
> >>>>> No more custom modules, no more userspace modifications [..]
> >>>>
> >>>> For our particular use case, we are running the skb through the kernel
> >>>> function `skb_validate_network_len()` with custom mtu size [..]
>
> (the function name is skb_gso_validate_network_len, my mistake)
>
> I previously expressed strong opinion that our "hack" to send icmp rejects on
> Layer 2 will not be useful for anyone else. But the existence of the commit from
> Michael Braun proves that I was wrong, and Jan Engelhards was right: it probably
> makes sense to implement the functionality that we need within the "new" nft
> infrastructure.
Yes, just do what Jan suggested and expost this in nft_meta.c
> As far as I understand, the part that is missing in the existing implementation
> is exposure (in some form) of `skb_gso_validate_network_len()` function to
> user-configurable filters.
No, nft already has "< $value" logic.
The only missing piece of the puzzle is a way to populate an nft
register with the "size per segment" value.
> Because the kernel does now expose the _size_ under
> which a gso skb can be segmented, but only the _boolean_ with the meaning "this
> gso skb can fit in mtu that you've specified",
It would be best to remove "static" from skb_gso_network_seglen() and
add an EXPORT_SYMBOL_GPL for it.
Then, extend nft_meta.c to set register content to that for gso
or the ip/ipv6 packet size for !gso.
Then, extend nft to support something like
nft insert rule bridge filter FORWARD \
ip frag-off & 0x4000 != 0 \
ip protocol tcp \
meta nh_segment_length > 1400 \
reject with icmp type frag-needed
[ NB: I suck at naming, so feel free to come up
with somethng more descriptive than "nh_segment_length".
l3size? nh-len...? ]
