From nobody Mon Oct 14 11:00:45 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 4XRvR45RL6z5YN3n for ; Mon, 14 Oct 2024 11:00:48 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XRvR44tLTz3xZs for ; Mon, 14 Oct 2024 11:00:48 +0000 (UTC) (envelope-from igoro@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728903648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=J6NOpsv6m8u1+9+Aewqb1dBjqVzkTyhLkJocWvFiqD4=; b=QoiJM/ZjgS/n5olM2ElK3h7tcUya+IKpKcNXoP9S2rvTtxqQlTqXkGQT+gidBCqD91f+Cq p2bFXliq7Dx5iHI2dSiwQ+DorkB20CwnhST/M2j5xDsnFYoEDAkJ3cRFvhBKXjw9aqRqO4 GsuIM/NqlSEimm2ZLQtjOFgKsaWToFQPHc1PZeRiG+StnUOV1Al9XAbYpR7bXysNCSV3Bh lDCsXGKe33qtTwueLSnwG+zIWTRqYNUrtnJixtH7kw5dntELRpm6CSG8VPGdb/e0pszZ70 Vl++4ht67iHrLHdlCKa3Z8w6HW6xetQXLUVQtad4DuJHlWudmAITTleffFrO/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728903648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=J6NOpsv6m8u1+9+Aewqb1dBjqVzkTyhLkJocWvFiqD4=; b=F4wqqtNnrc0pmgcqSHqEzi9OYjhcGMN/Akf/wYqD+w1K53t5maaljqnLfojoK7lSqpMbMZ 95B3zS1KJDMqUrRU66KpURPPfh9RNLbIvHu6Aug8y/iWxYDiJJBc7S0nY4cycbhF6Oa2wM UboMyxZv/UR0zqV9mIeWF99R88XAiPCpsiGFRaqoRg3f1tM5xxOfOKlMkZcErZ6Fe85QeN S8xYViUXJAHiyxDuc+zZRPxoKYlMuFvxPkWb2DVRWbNSxTf7S0jfA7EFCyAGoB8jtn+ZJq 2O4hraQpn+bW+buk0i2y0KCB9HoiBu8DGhOai/oR49LzJ75jdYj/J8GD09i+mw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1728903648; a=rsa-sha256; cv=none; b=Ky25q5qtpUO528mbXYj+lCXhZASDpUvZd+CdNCmMrjXQZeMp96szkX58ypQftrcuuyfqc1 dZ3VLfRXBnUvrA343a+Ctdknmchk4ivCl25MsR7oakTYK++BKBAkMBsZ8c9nox1i56GrK0 UlFSaGrI1+ZQzv3Nu9VXOgY5xHjBb2sM+d5GoPY7YT2cZLmx7bPaLonlGfhleg912SQJWT DeGsdVuXn9ibyzuXpWTWvx5fc3vFOf6nG4B1pDk4ys+vnsSAr7RMhthQ3yA4uPSs0gZT3Y ZNza8cNmRC5NriJhp3PzvyArxQTGbBKs3lzDPs1clL64JardltbXScW24yj1lA== Received: from [192.168.0.101] (unknown [78.83.216.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: igoro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XRvR42gpVz1LGC for ; Mon, 14 Oct 2024 11:00:48 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Message-ID: <05e3056e-4563-4d42-9e5a-6db0ea6bf90f@FreeBSD.org> Date: Mon, 14 Oct 2024 14:00:45 +0300 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 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Igor Ostapenko Subject: RFC: mbuf: Add m_len assertion to mtod() and mtodo() To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi FreeBSD developers, After the recent findings that a network module may end up doing things like mtod(m, struct ip *) over an empty mbuf in a chain, an idea has come to add m_len assertion to the existing mtod() and mtodo() macros. Thus, mtod() would panic if m->m_len < sizeof(struct ip) in the example. The current implementation proposal is here: https://reviews.freebsd.org/D46684 The high level technical plan for this long path is as follows: 1. Fix compilation cases 2. Fix runtime cases, e.g. mtod() can be used before m_len is prepared 3. Land the assertion The very first inconvenience found is that it will make mtod() unavailable for the following two use cases: - void pointer mtod(m, void *) - work with m_data pointer itself: mtod(m, vm_offset_t) mtod(m, uintptr_t) & 3 Currently, 116 void* cases and 60 m_data pointer cases are found [1]. And they are targeted to be re-worked. It's planned to consider each case because of something could be not just a literal macro expansion, e.g. mtod() & 3 examples could be changed to something like m_alignment(m) & 3 or m_is_aligned(m, 3). It would be appreciated to receive comments, opinions, and suggestions before starting work on the respective changes. [1] The cases found: https://github.com/ihoro/freebsd-src/pull/31/files Best regards, igoro