From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 8E7CB17981; Mon, 01 Sep 2025 14:13:05 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 6FF5A1791D; Mon, 01 Sep 2025 14:13:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2, SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by atuin.qyliss.net (Postfix) with ESMTPS id AAFB3178FF for ; Mon, 01 Sep 2025 14:13:02 +0000 (UTC) Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id ECEA814001F6; Mon, 1 Sep 2025 10:13:01 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Mon, 01 Sep 2025 10:13:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1756735981; x=1756822381; bh=jFbi9wUWZo HdI6ZItjMG76tTrCuIzibzbK7SZRk8otM=; b=pgbJsjDpFglgFfc+zuPPD1aj1b s6katH/2hflvU1ZkM1XBFZmrhBs0WxJVAKktrucoaJAWON7F3UTPWvzw5mjHEFrc OV0aDRAkwRB30Ki+OZ2iwaNBpQKU+jvA3hRJqdZ+IAde5kL0/2xsLUkQ72V0+pQc 4M76yZQ9c/GkpgjaXg5TsgHXzuYn1QLTLl1Hb4vR783Rlj4AkHLIEiD6OGo28g05 nxKWdyu9fEI2EvFGIVcY22hm/+Jq76kbWnDHhy/Xw+k7KemNbKvN1bfLOPKnSC2l KeCXnGUiO2dbrTLRWkre1+GsNtmVtxys7Rc0CouNMsJ88rYHjlydHdd2j3lA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1756735981; x=1756822381; bh=jFbi9wUWZoHdI6ZItjMG76tTrCuIzibzbK7 SZRk8otM=; b=DCI6CYY07j6esiFvTBNYPkfNbFL5aXV/yfPpWOc480+zSQJXcY4 tZHA52xCi3Nl+ebow9B8dUobCAuBvq2DD4o5F0oBgYJ7yUOVqM7R9PVQp1kDL7HJ 9RICVMlq5DVwsEL8YkgaiudNcY5/OsWQpLtlvhRCvIVfzprzujBhu4/IC/8QKkz/ OIc7rirADh5LxXRfHaodq5mgI0b5wO14M6zvEWR0SoF6CIgj5jVehYHoi5oAiQY5 2dVLmGp236m3GWOgAJQSXM4FTRM0CRfinySzCvZ6afnySOXgo21Myju5d1A3C65t lme42KqO9SiklPQmLa+sAWsjmOjY7fhuvcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduledvfeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefhvfevufgjfhffkfggtgesghdtreertd dttdenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheq necuggftrfgrthhtvghrnhepieduffeuieelgfetgfdttddtkeekheekgfehkedufeevte egfeeiffetvdetueevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhephhhisegrlhihshhsrgdrihhspdhnsggprhgtphhtthhopedvpdhmohguvg epshhmthhpohhuthdprhgtphhtthhopeguvghvvghlsehsphgvtghtrhhumhdqohhsrdho rhhgpdhrtghpthhtohephihukhgrseihuhhkrgdruggvvh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 1 Sep 2025 10:13:01 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 6340F15EF716; Mon, 01 Sep 2025 16:12:50 +0200 (CEST) From: Alyssa Ross To: Yureka Subject: Re: [DO_NOT_APPLY 1/2] integrate xdp-forwarder into net-vm In-Reply-To: <199f3fa9-d652-4281-8908-7294ac042434@yuka.dev> References: <20250823222134.1772413-1-yureka@cyberchaos.dev> <20250823222134.1772413-2-yureka@cyberchaos.dev> <87bjnxt6qn.fsf@alyssa.is> <87ms7ep92a.fsf@alyssa.is> <199f3fa9-d652-4281-8908-7294ac042434@yuka.dev> Date: Mon, 01 Sep 2025 16:12:48 +0200 Message-ID: <87iki2p8gv.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: UKNSVPF6DWHQG36CPYUPQRSY2QINWUPA X-Message-ID-Hash: UKNSVPF6DWHQG36CPYUPQRSY2QINWUPA X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Yureka writes: > Pointer arithmetics always work in pointer lengths, so + 1 is adding=20 > sizeof(struct ethhdr) bytes. > > eth is the beginning of the eth header. > > eth + 1 is the first byte after the eth header, or where the next eth=20 > header would begin in an array. I've figured out the source of my confusion. I mistakenly assumed that data_end would be a pointer to the last byte of data. It's actually a pointer to the byte after the last byte of data. > On 9/1/25 15:59, Alyssa Ross wrote: >> Yureka writes: >> >>>>> + >>>>> + /* Byte-count bounds check; check if current pointer + size of head= er >>>>> + * is after data_end. >>>>> + */ >>>>> + if ((void *) (eth + 1) > data_end) >>>>> + return -1; >>>> This is checking that there's more data after the header, right? Is >>>> that something it's important for us to check? >>> The intent is to check that the entire eth hdr, which we casted a >>> pointer to, is within the data (length) of the packet before we >>> de-reference the pointer. So essentially, skipping packets which do not >>> have a full ethernet header, instead of reading from addresses which we >>> are not supposed to read from. >>> >>> When loading the XDP program, it is tested against an empty or very >>> small packet, and if it tries to access memory outside of the packet >>> bounds, it will refuse to load. So the BPF/XDP system ensures that these >>> kinds of packets are handled properly. >> Doesn't using > instead of >=3D check that the entire eth hdr **plus one >> byte** is within the packet, though? i.e. wouldn't this check fail if >> the data consisted entirely of an ethernet header? Is that the right >> thing to do? (Sorry if my maths is just wrong.) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaLWp4AAKCRBbRZGEIw/w os9cAPkBQq/RMD6rDZzqMDJhqsRwFy/krRtBOAelSbK+Dys5DQEApnfP+1pLfSws inL8w6cp0OmabKcm01bTpIXWO2vDywg= =KyRm -----END PGP SIGNATURE----- --=-=-=--