From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id F11BC5A005E for ; Thu, 17 Nov 2022 15:23:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668694988; 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=KB5/ZTvjrcl9ZmteOdxKUMxoaAjnDbRoUkIKxTwT+kE=; b=CTmQVzKv6YS5qOaRHNB1AQOFiykYoHGNsy7oI78NzvrclErSVMo+2N8XLp3+X/MKyd8H2M /m8asQaxQ/F001u+HLo9UgsU/7eebOCjKERA4nXJuWm+KupDTNnMtwGjw7pZ/pHspP0xsN X6QuO4ZYIqIqHehYyU1aYYLUkX8VCLE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-668-vXwddpxMP7SCxyMYi113EQ-1; Thu, 17 Nov 2022 09:23:07 -0500 X-MC-Unique: vXwddpxMP7SCxyMYi113EQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 503EB185A794 for ; Thu, 17 Nov 2022 14:23:07 +0000 (UTC) Received: from maya.cloud.tilaa.com (ovpn-208-8.brq.redhat.com [10.40.208.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1837EC158CF; Thu, 17 Nov 2022 14:23:07 +0000 (UTC) Date: Thu, 17 Nov 2022 15:22:55 +0100 From: Stefano Brivio To: "Richard W.M. Jones" Subject: Re: [PATCH passt 4/5] XXX build: Add extra syscalls needed by AFL instrumentation Message-ID: <20221117152255.09a3d2c3@elisabeth> In-Reply-To: <20221117122614.1269214-5-rjones@redhat.com> References: <20221117122614.1269214-1-rjones@redhat.com> <20221117122614.1269214-5-rjones@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: PRK7VEIXZIUJAR37KZ7JTIKEYDOLTK77 X-Message-ID-Hash: PRK7VEIXZIUJAR37KZ7JTIKEYDOLTK77 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: passt-dev@passt.top X-Mailman-Version: 3.3.3 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 Thu, 17 Nov 2022 12:26:13 +0000 "Richard W.M. Jones" wrote: > This is a hack. Ideally there'd be a way to build a "non-production" > build of passt which would turn off all the encapsulation features. > They are not relevant for fuzzing and simply add overhead. I'm not sure how quantitatively relevant this is, but I was thinking about cases where sandboxing or "security" features cause issues (not necessarily security-relevant ones) that would be discovered by fuzzing. Partially fitting example: https://archives.passt.top/passt-dev/20221115012400.2240327-1-sbrivio@redhat.com/ there, perror() in glibc results in a dup() call, with seccomp terminating the proceess, in a way that was totally unexpected to me. Should fuzzing trigger a case like this one, without a seccomp filter loaded, we won't notice. Now, the guest affecting its own availability isn't security relevant, and that's the worst that can happen, but still it would be something to fix. Considering this, I'm actually more inclined to polish your hack (into an 'afl' Makefile target or similar). -- Stefano