netdev - Re: [PATCH v2 net-next 1/1] net sched actions: mirred add support for setting Dst MAC address

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:	Mon, 04 Jul 2016 15:14:35 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jhs@...atatu.com
Cc:	netdev@...r.kernel.org, daniel@...earbox.net,
	xiyou.wangcong@...il.com, nikolay@...ulusnetworks.com
Subject: Re: [PATCH v2 net-next 1/1] net sched actions: mirred add support
 for setting Dst MAC address

From: Jamal Hadi Salim <jhs@...atatu.com>
Date: Sat,  2 Jul 2016 10:34:25 -0400

> From: Jamal Hadi Salim <jhs@...atatu.com>
> 
> Often redirecting or mirroring requires that we set the dstMAC address
> of the target device. While it is possible to pipe to a pedit action,
> this patch obsoletes the need for that. This is a justified feature because
> the dst MAC addresses rewrite is such a common use case.
> 
> Sample usage:
> sudo $TC filter add dev $ETH parent 1: protocol ip prio 10 \
> u32 match ip protocol 1 0xff flowid 1:2 \
> action mirred egress redirect dev $SPANPORT dst 02:15:15:15:15:15
> 
> This will match all icmp packets going out on dev $ETH and
> redirect them to dev $SPANPORT while setting their dst MAC address
> to 02:15:15:15:15:15
> 
> Signed-off-by: Jamal Hadi Salim <jhs@...atatu.com>

I agree with Jiri.

The whole model is to chain together the actions that you need to
accomplish whatever it is you want to do.

This means actions are as specialized as possible, and do one thing
as precisely and efficiently as possible.

It seems unnecessary to break this model and start to make swiss army
knife actions.

Every time we find some "common use case" will we turn yet another
action into a Frankenstein thing that does more than it was designed
to do?

I don't want to apply this and start us down this road, seriously...