netdev - Re: [RFC PATCH net-next 0/3] L3 RX handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Aug 2015 22:14:04 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dsa@...ulusnetworks.com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next 0/3] L3 RX handler

From: David Ahern <dsa@...ulusnetworks.com>
Date: Fri, 28 Aug 2015 17:34:20 -0700

> Currently the VRF driver registers an Rx handler for enslaved devices.
> The handler switches the skb->dev to the VRF device and sends it back for
> another pass. While this works fine a side effect is that it bypasses
> netfilter with the skb set to the original device.
> 
> Looking at how to provide that feature a few options come to mind:
> 1. Have the rx handler in the VRF driver duplicate some of the processing
>    of ip_rcv up to the NF_HOOK and then switch the skb->dev to vrf device.
> 
> 2. Run NF_HOOK in ip_rcv twice -- once with orig_dev and then again for dev.
> 
> 3. Introduce an L3 rx-handler that provides the option of hooking packets
>    at L3 rather than the current backlog loop.
> 
> This RFC looks at option 3. I wanted to get opinions on the approach
> versus other options.

No way, this is not going to pass.

I've been playing my trumpet supporting this work, but as time wears
on and we are adding more and more hacks all over the tree I like this
VRF infrastructure less and less.

If you cannot figure out the right clean abstraction for what you want
to do, SIT AND WAIT.  Think about it for a while instead of posting
"yet another hook" type changes like this.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html