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=K1AanKxq; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 803375A0265 for ; Fri, 14 Aug 2026 09:36:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786692964; 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=1WrScORq+cN30t4Tslz22Y7MdtAAkWhMOM11xjNWUAI=; b=K1AanKxq49BiR81qSsQvPthgmY1+u8Z/9Jq5Ib81r5I5m08MhDyjaFgBeHdKH7wdafFmUT pRxTlKyw2dWg4BTgbZI5Q6Ya+9bKxhyt8ThYeEfNUq02+N5lde69i1aBFf+sG0LZT9yZI1 ZzJ/HAnb60L5dGlhqsaw+l9jm9iVNj4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-500-6wDuer_aOO60wdf9Sryzcw-1; Fri, 14 Aug 2026 03:36:03 -0400 X-MC-Unique: 6wDuer_aOO60wdf9Sryzcw-1 X-Mimecast-MFC-AGG-ID: 6wDuer_aOO60wdf9Sryzcw_1786692962 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-473ac08a6a4so439108f8f.0 for ; Fri, 14 Aug 2026 00:36:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786692962; x=1787297762; 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=1WrScORq+cN30t4Tslz22Y7MdtAAkWhMOM11xjNWUAI=; b=nLjwgqz2NePbwzu44++1j2Ti1b2T2oPrCHLK/hSiD8w1d5F15Z89stKwavCQFWdJTD 4TpDiKVuiqU/yAPcA0D5v1GK0hlig3tt/Gop9/m5b96eRkRZACvxomVNkWb9gSigoxGp F7sjUZzz4/3gwVc1DkOP2aNAAxgZZG7aWnF1ADLLwLts8ymDjH9scppOl6tgM8I7hQCK 13YJHQSsM1IzAIAUh+4iQV4NXy3uFI4FNsUYCr18WJ3O9eVu+d1OgDz0i6lV++6HJmD/ 4zi4/HjUI4hmQ9RkCYdj0ZiCVqBVQ+mWjKD4DSl4/ov5TTjsAJIDu/cOrD80DEi1mz2W U5qg== X-Forwarded-Encrypted: i=1; AHgh+RrKyj1HkjYD0lTN2wr2YMYXlZZ7scHobjuvrgCyNVCEy70S66OAuWXzeTwS7VQtLCyo1M9G+pg1CLg=@passt.top X-Gm-Message-State: AOJu0YwnV7YHjtJV8U/sLSHH05VfZr5JPjnT5Ky/69P9k2hhn3ZZ6eBp SSz0e4Zm3HhYGC7EAsmI/e9ghX3y/NumSgST3D+TzzsN1ys3imJE9k/c+ucdol346jwJgfn9QTA poBgaJ4ZSpP2PK6kuToDeh5XHV3qfF05401+R9zPHz8/doGzY6kFdLQ== X-Gm-Gg: AR+sD13zKQ70WbnO/cdbelpIqovyjgjSSUqT4XMYP6Xpw5BYQYnLneW9JAx67DQqYUj N64g7/Vi8VPvnZs94MlomWay2NHfmS59m3xEH9WrXC/1Q0BekcMgIyAUBQmv6WwEAknrexWiPRD Nx0wkEAMjzTYxlNQbBnuRpN2HlhgregvfiUzDn61r7LXRGfUFPOXbaQJH18GL2ulkegimbyHi4d z6MBCyG+zaIx7je9z3Fohh217flYKkEspBT7A7G+qTVnP1xMRaRDcp9oygobKzgeiC76rgtGmMC uTN+tMK2hlZuRg1WcPT7jEKnVnPSxcxhDLK3lTgyic9ElZpUIcTtbGkZ4zKaCtvmGpsK8owmyGp OV/kl16fzmac= X-Received: by 2002:a05:600c:5397:b0:493:bb6b:5bb5 with SMTP id 5b1f17b1804b1-499879857d0mr48367365e9.13.1786692961093; Fri, 14 Aug 2026 00:36:01 -0700 (PDT) X-Received: by 2002:a05:600c:5397:b0:493:bb6b:5bb5 with SMTP id 5b1f17b1804b1-499879857d0mr48366335e9.13.1786692960502; Fri, 14 Aug 2026 00:36:00 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f20051esm6593086f8f.7.2026.08.14.00.35.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 00:35:59 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 5/5] fuzz: Add test server for bidirectional protocol fuzzing Message-ID: <20260814093558.41626ef3@elisabeth> In-Reply-To: References: <20260812072630.3235261-1-anskuma@redhat.com> <20260812072630.3235261-6-anskuma@redhat.com> <20260813095323.4c2719bd@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Fri, 14 Aug 2026 09:35:59 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: bfBJs5z77PtqSCM_gHddH8ynBQ1yaAHo3Kw07vVLr0w_1786692962 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 6P5FILCWH423GAK2MJR4AHUJD56BMVQZ X-Message-ID-Hash: 6P5FILCWH423GAK2MJR4AHUJD56BMVQZ 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: Anshu Kumari , 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 Fri, 14 Aug 2026 15:40:35 +1000 David Gibson wrote: > On Thu, Aug 13, 2026 at 09:53:24AM +0200, Stefano Brivio wrote: > > 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. > > It does. > > > 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). > > So, I agree that to meaningfully fuzz things, we want the fuzzer to be > able to control data on both the guest and host side. I can see two > basic approaches: > > A) Alter passt/pasta so that instead of directly communicating with > external entities (either guest or host side) we use mocked > versions which retrieve data from AFL. We can do that either at > the system call level, or at a higher helper function level, the > lower level we go, the more of the "normal" passt code we're > exercising, but doing at a slightly higher level might be easier > to implement > > B) Run passt/pasta in an environment where we can intercept the > external transfers to a test server / test peer / test guest which > in turn responds based on data from AFL. > > Both the current draft and the sketch diagram Stefano has provided are > a hybrid of both approaches, so far I'm not seeing a clear advantage > to that over going all one way or the other. Of course, B) would be cleaner (and not that complicated, see below), but we don't want to do that guest-side (sending data from a test guest) because we would lose the speed advantage of having shared memory on the path that _really_ matters for fuzzing (the guest is untrusted, the kernel isn't). That's something we already established a while ago when AbdAlRahman was working on it. We hadn't really looked into the host side yet, back then. So, host side: we can't do it (and it's much less important) because we need to use those sockets in the same way passt uses them. The guest side interface is a trivial recv(), the host side is something complicated with iovecs and everything. > (B) is quite easy to do guest side - we just connect a "test guest" to > passt's socket. Approach B is much harder for host side. The current > draft has a test server listening on a single address. This is just to get something up and running though, it obviously needs to be changed later. > But that means > the fuzzing is fundamentally incapable of finding bugs involving > talking to multiple peers at once. Worse, we have to constrain the > construction of guest side data so that we talk to the test server not > something else, and that's one of the things we most want to fuzz. > > To really take approach B for the host side we'd need to intercept > *all* host side network traffic regardless of address. Probably > easiest way to do that would be put the whole thing inside another > netns. That outside netns would have a default route to a tap device, > and on the other side of the tap device would be a test server serving > up frames built from the fuzzer output. As I was mentioning, this could be done in a network namespace without any interface, by making the test server listen to all ports and all addresses, with a non-local bind and a so-called AnyIP route. Tested: $ pasta -- sh -c 'ip route add local default dev lo; nc -l 1 & { sleep 1; echo x | nc -N 1.2.3.4 1; }' x > It's probably easier to co-ordinate if the host side and guest side > test server is the same, so we'd have: > > ,-------. ,-------------. > | AFL++ |-- shares memory with ---| test peer | > '-------' '--v------v---' > | | > /-tap device-/ | > | | > /- test netns ----------^-------------------|-------------\ > | | | > | ,--------. | | > | | passt >----------------/ | > | '--------' | > \---------------------------------------------------------/ > > The test peer generates host side frames via the tap device, and guest > side frames via the Unix socket. The UNIX socket is something we want to avoid, it's really much slower compared to shared memory (we tried something like that) on the path where AFL++ is trying to mutate data fast (because it can hit a lot of different code paths with small changes, compared to changing socket-side payload). > It could also be done with pasta, like this: > > ,-------. ,-------------. > | AFL++ |-- shares memory with ---| test peer | > '-------' '--v------v---' > | | > /-tap device-/ packet > | socket > /- test netns ----------^-------------------|-------------\ > | | | > | ,--------. ,----------------|---. | > | | pasta >-tap device-< guest netns * | | > | '--------' '--------------------' | > \---------------------------------------------------------/ > > > The order it generates host vs. guest frames should also come from the > fuzzer, not be fixed. At least theoretically, this is non-invasive: > it could run with an unmodified passt/pasta. Except that > - AFL would still need coverage feedback from passt/pasta > - It wouldn't allow us to simulate odd timings (except by actually > expending real time) > - The various interposing layers will probably slow down fuzzing. > > So, I rather suspect it will work better to go fully to approach A: no > test peer at all, instead passt itself is modified to use mocked > versions of all the external syscalls to slurp data from AFL. The > draft series already does this for epoll_wait() and recv*(), but we'd > need to also do that for recv*() on the tap socket, connect(), > accept(), TCP_INFO and probably others. We'd also need to mock > "sending" calls, send(), write() and shutdown() at least - but those > could probably be no-ops. ...except that by mocking all those we lose a lot of complexity where historically we had a ton of bugs. If we just mock recv() it's much less (well yes we had bugs there as well but it was like 3 or 4 over the entire project history). > This is more invasive, of course. It also means we need to deal with > the case where AFL generates a syscall results that should be > impossible - that should move onto the next case ASAP, but not be > flagged as a passt bug. On the other hand, this approach should be > fast, and since we can also mock clock_gettime(), the fuzzer can > potentially find timer logic bugs that would only occur after hours or > days in real time. > > > 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