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 D6F3C17834; Mon, 01 Sep 2025 14:04:44 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 6710117814; Mon, 01 Sep 2025 14:04:42 +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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail.cyberchaos.dev (mail.cyberchaos.dev [IPv6:2a0f:4ac0::3a11]) by atuin.qyliss.net (Postfix) with ESMTPS id 2C67D17810 for ; Mon, 01 Sep 2025 14:04:41 +0000 (UTC) Message-ID: <199f3fa9-d652-4281-8908-7294ac042434@yuka.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuka.dev; s=mail; t=1756735478; 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=G/h20l5g4x9qEeFnJ1zbHT3G37POr2pdoVma/Xg/8q4=; b=jOfMHQCz17VcrFCgua0jWqbF1z+DcFYCu0kRt3D9rwR9uEhxAeDWD0yn13piIDVWxAjOiB Yeaq0Vob5os3xy8ete+OHzBOstEJiVDQ7o+OED/SdRTT3yfrevpzr+3bma0ddyw5dy9qdd K/T57zFr8V3eHmVMPeEpAsVyvPUaSG4= Date: Mon, 1 Sep 2025 16:04:37 +0200 MIME-Version: 1.0 From: Yureka Subject: Re: [DO_NOT_APPLY 1/2] integrate xdp-forwarder into net-vm To: Alyssa Ross References: <20250823222134.1772413-1-yureka@cyberchaos.dev> <20250823222134.1772413-2-yureka@cyberchaos.dev> <87bjnxt6qn.fsf@alyssa.is> <87ms7ep92a.fsf@alyssa.is> Content-Language: en-US In-Reply-To: <87ms7ep92a.fsf@alyssa.is> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: BSIXJAGRXYDNNDMG7QNU4Z7ZONLB6WZJ X-Message-ID-Hash: BSIXJAGRXYDNNDMG7QNU4Z7ZONLB6WZJ X-MailFrom: yuka@yuka.dev 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: Pointer arithmetics always work in pointer lengths, so + 1 is adding 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 header would begin in an array. On 9/1/25 15:59, Alyssa Ross wrote: > Yureka writes: > >>>> + >>>> + /* Byte-count bounds check; check if current pointer + size of header >>>> + * 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 >= 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.)