Date: Sun, 3 Nov 2013 09:28:05 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Mark R V Murray <mark@grondar.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r257535 - head/sys/netgraph Message-ID: <20131103091238.S1004@besplex.bde.org> In-Reply-To: <0FD2B8FA-7DD7-4626-95F6-BB64B648E81A@grondar.org> References: <201311020011.rA20BchL020170@svn.freebsd.org> <20131102151309.A1102@besplex.bde.org> <CAJ-VmokeP5Z2d7jZ-j-Thrh_VuQBKGpKC9nWG%2BQfhR0f6wzF9w@mail.gmail.com> <76BC3F76-ED5E-42F0-BCCE-271EA723698E@grondar.org> <0FD2B8FA-7DD7-4626-95F6-BB64B648E81A@grondar.org>
index | next in thread | previous in thread | raw e-mail
On Sat, 2 Nov 2013, Mark R V Murray wrote: > On 2 Nov 2013, at 09:32, Mark R V Murray <mark@grondar.org> wrote: >>> Mark - did you initially mean the address of the mbuf m_data pointer, >>> or the data payload itself? >> >> As Bruce says - the address of payload data itself. We don’t have 12-byte pointers in FreeBSD. :-) > > Cancel that. > > The address passed must be the address of the m_data field in the mbuf structure. The harvested data is 12 bytes from that address forward, so not the data pointed to by that m_data pointer but the pointer value itself and some following junk too. Is that really worth using? The mbuf data pointer is only slightly more random than the mbuf pointer (equally non-random if the data is in the mbuf). The bytes following it are even less random. I think the mbuf pointer usually points to an IP header. 12 bytes gives everything except the source and destination addresses. 20 would cover those too. There can't be buffer overruns in practice, even with a much larger size since small buffers go in the mbuf. In the mbuf header starting at the data pointer, there are always 16 bytes in the header alone, and many more after the header. On 32-bit systems, the header has 2 more bytes in mh_type after the 12 followed by 2 bytes of unnamed padding. The padding might be random but is more likely to be always 0. 16 altogether. On 64-bit systems, the header has 4 more bytes in mh_flags after the 12, then 2+2 for mh_type and padding as above, then 4 more of unnamed padding. 24 altogether. So why 12? Brucehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131103091238.S1004>