netdev - [RFC net-next v2 0/5] net: openvswitch: Add sample multicasting.

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-next>] [day] [month] [year] [list]

Date: Mon,  8 Apr 2024 14:57:39 +0200
From: Adrian Moreno <amorenoz@...hat.com>
To: netdev@...r.kernel.org
Cc: Adrian Moreno <amorenoz@...hat.com>,
	jiri@...nulli.us,
	xiyou.wangcong@...il.com,
	cmi@...dia.com,
	yotam.gi@...il.com,
	i.maximets@....org,
	aconole@...hat.com,
	echaudro@...hat.com,
	horms@...nel.org
Subject: [RFC net-next v2 0/5] net: openvswitch: Add sample multicasting.

** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's handler
threads only to be forwarded to some third party application that
will somehow process the sample and provide observability on the
datapath.

A particularly interesting use-case is controller-driven
per-flow IPFIX sampling where the OpenFlow controller can add metadata
to samples (via two 32bit integers) and this metadata is then available
to the sample-collecting system for correlation.

** Problem **
The fact that sampled traffic share netlink sockets and handler thread
time with upcalls, apart from being a performance bottleneck in the
sample extraction itself, can severely compromise the datapath,
yielding this solution unfit for highly loaded production systems.

Users are left with little options other than guessing what sampling
rate will be OK for their traffic pattern and system load and dealing
with the lost accuracy.

Looking at available infrastructure, an obvious candidated would be
to use psample. However, it's current state does not help with the
use-case at stake because sampled packets do not contain user-defined
metadata.

** Proposal **
In this RFC_v2, I'd like to request feedback on an attempt to fix this
situation by:

- Extending the existing psample infrastructure to carry a variable
length user-defined cookie.
- Extending the tc act_sample action to use the actions' cookie as
psample metadata.
- Extending the OVS sample action with an attribute
(OVS_SAMPLE_ATTR_PSAMPLE) that contains a u32 group_id and a variable
length cookie and use the the psample infrastructure to multicast
the sample.
- Extending psample to allow group_id filtering on listening sockets so
that users can only receive samples they are interested in.

--
rfc_v1 -> rfc_v2:
- Use psample instead of a new OVS-only multicast group.
- Extend psample and tc with a user-defined cookie.

Adrian Moreno (5):
  net: netlink: export genl private pointer getters
  net: psample: add multicast filtering on group_id
  net: psample: add user cookie
  net:sched:act_sample: add action cookie to sample
  net:openvswitch: add psample support

 include/net/psample.h            |   2 +
 include/uapi/linux/openvswitch.h |  22 ++++-
 include/uapi/linux/psample.h     |   2 +
 net/netlink/genetlink.c          |   2 +
 net/openvswitch/actions.c        |  52 ++++++++++--
 net/openvswitch/datapath.c       |   2 +-
 net/openvswitch/flow_netlink.c   |  78 +++++++++++++----
 net/psample/psample.c            | 139 +++++++++++++++++++++++++++++--
 net/sched/act_sample.c           |  12 +++
 9 files changed, 277 insertions(+), 34 deletions(-)

-- 
2.44.0