From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bzhRM1mO; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 5294A5A0272 for ; Thu, 13 Aug 2026 09:53:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786607610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A8kAdmVwtM0JqW5aeQdd02mt5Zrm3YpV+d28uQAi1Mg=; b=bzhRM1mOEkxcl/sJIOOYny3FQ+59Pc7nHirfd6f+cBhRRUJwBsqAv1pXAA34igWAA+DtoU RixBHzXk4FjfCogI0LzEzX0WlN7IYd42hnkS8nXfC9wMVBMecRu5pMSTYC/UTRIr2N/MgU AJNBdl4BVLzP1acqMLmKQKjtJ+dqCRE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-645-BcxmJiIlNKGB5LGQMn8FAw-1; Thu, 13 Aug 2026 03:53:28 -0400 X-MC-Unique: BcxmJiIlNKGB5LGQMn8FAw-1 X-Mimecast-MFC-AGG-ID: BcxmJiIlNKGB5LGQMn8FAw_1786607607 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4955ce558d8so19640795e9.3 for ; Thu, 13 Aug 2026 00:53:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786607607; x=1787212407; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=A8kAdmVwtM0JqW5aeQdd02mt5Zrm3YpV+d28uQAi1Mg=; b=OKSHxcxU/n/iY2sbwx8h9uRVuD6cdbu7OhwApOun4TK5/SihE4GkZdLnk0YIA1D2Ra 8ZdK2w0uX7GTYJvdCWtWL6A5ziHYcLzafmRNCAgH/bT/vGgITLXSU4Pn7hyaZQWPbLIB w1+10LbnYpRf2pddWPlEbDN/yohWTYh7BVPgpDJxHxfyPeYY1D0jGqj5iLrOXlMzXnab KOj3HDPJR7kASZ8Q+Fr3oIRe0v2Ldd+uAlnaRZLjlFr1do6ueW9hQRPYZNIALIIGZSLi q2gAXeFfQfL0QLUEc42dfCUN7t+rGzuIFbEF7sHzo4VFaz4TbbXdDceJ0jtmB77EcTc2 /H0g== X-Forwarded-Encrypted: i=1; AHgh+Rp9uN9SXclJbtUCX2LMzTQ8zwZSauDtRj6qrPreFf//VHnp19zOsKh5viTkK5UzTKSu/mjoi8rO/PQ=@passt.top X-Gm-Message-State: AOJu0YyhU7X6We2QliryZwD9Ys9f0v152Wvyz4U+SVfLYg+eaZmQBz+T VgqWllgAhH6JOwso8JY04xmrIkdV3BkPn55ZZwUK3pUitqruqJ8IRrIeFsagyAAw7+ryVcA4AlT +4B0snTCqVOyEdk9kGf4H/mvny8zyzkFluhtjRkfwWotOGAi44xdUFw== X-Gm-Gg: AR+sD10hYiUtrSw4AAEz9KTOoiWp9WMezikFEZMRKEMhZs6o96hbdaAfyzuUBpNBcjJ wAGBWg2f7ZKqguXACM804GAvAFSUjgtDNiIHlW3Rihs5fLYy47jqGRg4e3b/CcL29fHMGC9Vx55 nhbCYsR7SSTQh5QKrydeTfFHcA7ou0ixql4N8g8Y7XvfUbSeNNlKm5sImGHzoKjRZZwsYcbkhMJ ZNe50KPrswJZCb87uzhnkZ/HepawHpKyEmkhVzpGcWhDEqvRgWHoSVI7qpFOwXR/TCZeF8Qp34Z 6UeCVEgmXmk+Yd9AkfswWD3liktnjbjfOaqmpfJGzQuHU9EukQTC1Rh8h1aJkMrSKdK9ZmLV1gk ve67NwAnKT1dNStByJdNewLqpQPzd X-Received: by 2002:a05:600c:154e:b0:499:737c:8a8b with SMTP id 5b1f17b1804b1-499821c9acbmr41313035e9.12.1786607607123; Thu, 13 Aug 2026 00:53:27 -0700 (PDT) X-Received: by 2002:a05:600c:154e:b0:499:737c:8a8b with SMTP id 5b1f17b1804b1-499821c9acbmr41312505e9.12.1786607606578; Thu, 13 Aug 2026 00:53:26 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b631c1sm97725765e9.14.2026.08.13.00.53.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 00:53:25 -0700 (PDT) From: Stefano Brivio To: Anshu Kumari Subject: Re: [PATCH 5/5] fuzz: Add test server for bidirectional protocol fuzzing Message-ID: <20260813095323.4c2719bd@elisabeth> In-Reply-To: <20260812072630.3235261-6-anskuma@redhat.com> References: <20260812072630.3235261-1-anskuma@redhat.com> <20260812072630.3235261-6-anskuma@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Thu, 13 Aug 2026 09:53:24 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: WMW7lNpXNxnrNfHgfB0IkYJzm1yTk5Wqu_qNADgNl94_1786607607 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GGFIZJ6GGAQI6R4HXWQB32DCGQEJFGKB X-Message-ID-Hash: GGFIZJ6GGAQI6R4HXWQB32DCGQEJFGKB X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: david@gibson.dropbear.id.au, passt-dev@passt.top, aerosound161@gmail.com, abdobngad@gmail.com, lvivier@redhat.com X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 12 Aug 2026 12:56:28 +0530 Anshu Kumari wrote: > Add fuzz-server that acts as passt's network peer > during fuzzing. To me, this part makes sense. But this one: > It connects to passt's UNIX socket much less, while: > and listens on 127.0.0.1:9999 for TCP connections. this is the part that I expected instead. Otherwise it's not just passt's network peer, it's the guest as well. > UNIX socket path: responds to ARP requests and TCP SYNs with > stateless replies (swapped addresses, fixed ISN). Responses > are XOR'd with AFL++ shared memory data so the fuzzer can > mutate server behavior. This looks rather complicated to me. The approach I was suggesting with a test server is the following: ,- exchanges guest-side data with ------------. | ,---------|---------. | ,--| passt | | / '-.---------------^-' ,---|---. / | connect(), | accept(), | AFL++ |-- shares memory with ---| | send data, | reply with '---|---' \ | etc. | data, etc. | \ ,-v---------------'-. | '--| test server | | '---------|---------' '- exchanges host-side data with -------------' ...at least in its basic form. Eventually, the test server should be able to connect to passt itself (and we could call it "test peer" at that point). As far as I understood, it's not trivial to make the same instance of AFL++ share memory with two processes at the same time, so the memory-sharing path might need to take a more complicated turn, for example there could be a wrapper starting both passt and the test server and sharing memory with them, or passt could _additionally_ (using a special out-of-band fuzzing channel) share data from AFL++ with the test server. An example of communication below (but events don't necessarily need to be in this order, this is just an example). For simplicity, let's ignore the fact that AFL++ might not directly share memory with passt and test server, and assume there are three areas of memory that AFL++ directly controls: a. shared with passt: an array of struct epoll_event, 'ev' b. shared with passt: the kind of tap-side buffer you implemented in 4/5, 'buf' c. shared with the test server: a separate buffer, 'test_buf' Example: 1. AFL++ writes an EPOLLIN event in 'ev' with type EPOLL_TYPE_TAP_PASST, of some data in 'buf', and some data in 'test_buf' 2. AFL++ starts passt and the test server 3. passt reads the EPOLL_TYPE_TAP_PASST event from 'ev', reads data from 'buf' and hands it to passt_tap_handler() 4. this happens to be have Ethernet, IP, and TCP headers, with the SYN flag set, and destination address set to the address of the test server (we might want to force all this, at least initially, or give it as a hint to AFL++ somehow), so passt connects to the test server 5. the test server accepts the connection, and sends the contents of 'test_buf' on it (for the test server, this is directly payload, without headers, as they don't make sense there). I'm not sure if we should have a different set of events (maybe we need a "play script" for the server, in case?) 6. this generates an EPOLLOUT event for passt. It's not in 'ev', it's a regular epoll_wait() (I think we could have an epoll_wait() loop where we additionally read one event from 'ev' for every iteration, or something like that) 7. passt marks the connection as established and inserts it in the flow table 8. passt reads the data sent from the test server and generates whatever TCP data packet to the "guest" (it might simply be a sink) ...and this attempt ends here because AFL++ generated a single event for passt, but there could be more (this should also be decided by AFL++). Would something like this make sense? -- Stefano