From nobody Thu Jul 11 12:44:11 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WKZDP6DHrz5QZJh for ; Thu, 11 Jul 2024 12:44:21 +0000 (UTC) (envelope-from igor.ostapenko@pm.me) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WKZDN3hFTz4nQl for ; Thu, 11 Jul 2024 12:44:20 +0000 (UTC) (envelope-from igor.ostapenko@pm.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pm.me header.s=protonmail3 header.b=ouA8RhPP; dmarc=pass (policy=quarantine) header.from=pm.me; spf=pass (mx1.freebsd.org: domain of igor.ostapenko@pm.me designates 185.70.40.133 as permitted sender) smtp.mailfrom=igor.ostapenko@pm.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1720701858; x=1720961058; bh=dW1XWTCUGGdnsKa98vvwkX+fekjVQhy22SLqScmIZhQ=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=ouA8RhPPFek9C0IPjJAwsPrf7osg5SRawf7FzO4aR76ifRxgttLRCqtFTa12Ioi01 V8lqieCw1Ulw5dCX3tecm6PZLP9e/PvPyocNnJ6nO9i5MYog91dvBfvMNLt9y9JSEc Y4Pmr50K8cxPNR3XplXdHd6/z4/CRaHwJ/JXRKZHmK/FxXN+0CUeD6SQ/oDHRWyFIe LLa9FcmYECCZkVZTH750xaTuPEhUf3d+OMQvtUKSAQA2xtWFWOAlf5reKz5/MxFdr+ xeZ7Bj6OLON3PkghvZk5pS4IF8+nFWqSe9GESwlOZTPWVWE6Xj6u6CrauZyOrHGPLS ixV/cfC/opPUQ== Date: Thu, 11 Jul 2024 12:44:11 +0000 To: "freebsd-net@freebsd.org" , "freebsd-testing@freebsd.org" From: Igor Ostapenko Subject: RFC: Add dummymbuf module for testing purposes Message-ID: Feedback-ID: 8300135:user:proton X-Pm-Message-ID: 74de44792da1126e6f6284031423707f6d3b3ec4 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[pm.me,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.133:from]; R_DKIM_ALLOW(-0.20)[pm.me:s=protonmail3]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.133:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[pm.me:+] X-Rspamd-Queue-Id: 4WKZDN3hFTz4nQl Hi FreeBSD developers, There is a need to test firewalls for a case when the first mbuf in a chain has m_len =3D=3D 0. It comes from a real issue found recently -- a specific= mix of kernel modules reveals a defect in the firewalls' behavior. The proposal is to provide a source of non-usual mbuf chains for the testing purposes in the scope of system/e2e type of tests. The idea is straightforward -- we could put another pfil(9) user in front o= f a firewall, which would alter a mbuf chain according to the given configuration before it hits a firewall. There is a working prototype, the current design of which is as follows: - A brand new module, dummymbuf, provides special pfil hooks. Such hooks are meant to be linked manually via pfilctl(8). - Newly added "net.dummymbuf.rules" sysctl is used for configuration, which is a list of rules applied sequentially. Each rule filters a packet by PFIL type (inet, inet6, ethernet), direction (in, out), and interface. Upon matching a specified operation is applied to a mbuf chain. Currently= , there is a single operation named "pull-head", which always allocates a new cluster in front of the chain and pulls a given number of bytes. Zero bytes pulled means to create a situation with the first mbuf of zero length. Non-matching packets are passed without modification. - It's designed to fail fast by dropping a packet in case of misconfiguration or other issues. - Additionally, there is "net.dummymbuf.hits" counter sysctl revealing the number of times any rule has been applied. It's expected to be used for extra checks to lower the chances of false positives if the module has defects or is misconfigured. - This is a VNET based solution. Parallel testing should be applicable. - A quick sneak peek to get use case intuition, for an atf-sh test case: pfilctl link -i dummymbuf:inet inet sysctl net.dummymbuf.rules=3D'inet in epair0b pull-head 0;' atf_check_equal "0" "$(sysctl -n net.dummymbuf.hits)" atf_check -s exit:0 -o ignore ping -c1 192.0.2.2 atf_check_equal "1" "$(sysctl -n net.dummymbuf.hits)" It would be very appreciated to hear opinions and suggestions. There may be high level organizational questions like whether it should hit the base or should be part of the test suite only, and so on. The WIP patch: https://reviews.freebsd.org/D45928 The usage example: https://reviews.freebsd.org/D45927 Best regards, Igor.