From nobody Sun Jan 30 05:40:43 2022 X-Original-To: bugs@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 D97A11992E6A for ; Sun, 30 Jan 2022 05:40:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jmg5l4NMdz4vXm for ; Sun, 30 Jan 2022 05:40:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7739F23728 for ; Sun, 30 Jan 2022 05:40:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 20U5ehUh086927 for ; Sun, 30 Jan 2022 05:40:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20U5ehN4086926 for bugs@FreeBSD.org; Sun, 30 Jan 2022 05:40:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 261566] Padding of DLT_PFLOG packets should be done differently Date: Sun, 30 Jan 2022 05:40:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gharris@sonic.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643521243; 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=u7OMUZT8a1eNUTtsn69UrsC6ah3877nVWNsAvkGKpJo=; b=S3YwoWLvBYGDgMofEMInJ3IRsTEZKNNjIFsjujzPRCL3PaCMpOscyBG994z74ww6E/sVc5 E+TeaXb1BdNJOwZoRX3hjFUKCGwKUvLs3DD/84Wm50EyfWbFLATxFhL5a99kOc9ifkR3Ej 9/0O+127Q6qqDNkDbTnboY9rUTQS3tyx6TiWN4Hi9jsDBp0jcZe33rOHgRd5ZX5HNR3Eyh v2ohkFdTnXieYVPAJWoIX+9ZOuIKSL6kU2c21iMZ3oelFSLXfW1GS2xMTRIlQ4atQ5ciHi MNnOYMZ/YU6SRmZU1st2HzrVOBWKMH0L5Fcv/QMaf743cVcudEsR0Ow/gox8qQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643521243; a=rsa-sha256; cv=none; b=u+SIedCtvRpwuEynE6CR0anildrIMPrVq7qAybJCTecke3kz1Tge6ZjfNILhCZxvueKah4 jAvGP3TFajj1WW7KKcjszj/m/ABab/FstLTUkhzVbnJJ4tFrgFkbW/Lb93sBxil9e619fA bbfSVhioSrAf2202fc+R4tOgQ6WGLy5OD6wvDhqDjWgQIfUxDESpe4sipVafChNB3lA6e3 amCRT1gsWdUh+ZoJ/8lwjRl+fwgHyxWxbllOsNr1e9NwPHpc5ZghlUvz3CdGqiTpl/8xWk oUmFb+0KiHdSYh2pdL3TDYZDKBS0y61k4Yaruylyv4O354b83LoLqoXCgWEtVw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261566 Bug ID: 261566 Summary: Padding of DLT_PFLOG packets should be done differently Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: gharris@sonic.net Currently, sys/net/if_pflog.h does #define PFLOG_HDRLEN BPF_WORDALIGN(offsetof(struct pfloghdr, pad2)) This is done only in FreeBSD; neither DragonFly BSD nor NetBSD nor OpenBSD = nor Darwin use BPF_WORDALIGN() here, and, as FreeBSD's BPF_WORDALIGN() aligns to the size of a long, this means that the DLT_PFLOG packet format can differ depending on whether the machine writing the packet is 32-bit (ILP32) or 64= -bit (LP64), which, given that neither the pcap file format nor the pcapng file format give any indication of the size of a long on the platform on which t= he file was written, means that the correct way to process a DLT_PFLOG packt i= n a given file cannot be determined from the file. The commit message for the commit that added BPF_WORDALIGN() was There were two issues with the new pflog packet length. The first is that the length is expected to be a multiple of sizeof(long), but we'd assumed it had to be a multiple of sizeof(uint32_t). but it gives not justification for the claim that "the length is expected t= o be a multiple of sizeof(long)". As indicated: 1) that's not the case on only *other* BSD-flavored OS with pflog and 2) that creates a packet format that can only be processed correctly by providing external information about the machine that wrote the file, which requires not only extra code, but extra time and energy on the part of whoever's trying to read the file, to determine the size of a long on the platform on which it was written and to supply that to the program reading = the file. The other OSes rely on the compiler to add the padding as a consequence of = the structure including some 32-bit integral values; that should suffice here, although if you want to make *sure* it's padded to a 4-byte boundary, you c= ould use roundup2() from sys/param.h to do it rather than dragging in net/bpf.h. Note that 1) it's not clear that aligning on an 8-byte boundary will provide any performance improvement, as, even if you were to align the IP packet on an 8-byte boundary, there's no guarantee that this will put a significant numb= er of 8-byte fields on an 8-byte boundary and 2) that will make a difference for two of the main packet analyzers that re= ad pcap and pcapng files (tcpdump and Wireshark) only on CPUs that 1) support unaligned access but 2) impose a penalty for those accesses. --=20 You are receiving this mail because: You are the assignee for the bug.=