On Feb 9, 2012, at 7:04 PM, Guy Harris wrote:
> *However*, that's not the only place where structures involving times get
> passed between the kernel and userland. They *also* get passed in the
> BIOCGRTIMEOUT and BIOCSRTIMEOUT ioctls, the argument to which is a pointer to
> a struct timeval. This being a BSD-flavored OS, the ioctl cookie includes
> the size of the structure, so an ioctl with a 32-bit struct timeval will have
> a different ioctl cookie from an ioctl with a 64-bit struct timeval.
>
> From a quick look at the top of the trunk, _BSD_TIME_T_ is always defined as
> __int64_t and _BSD_SUSECONDS_T_ is always defined as int, so struct timeval
> would, *modulo padding at the end* (I presume that's the "48bits for i386 and
> 64bits for amd64" - presumably meaning "48 bits for 32-bit platforms and 64
> bits for 64-bit platforms"), be laid out the same, so that should work as
> well.
Except that the padding means that the ioctl cookies will be different, so
32-bit code that attempts a BIOCSRTIMEOUT on a 64-bit kernel will succeed only
if the kernel has a case in the switch statement to handle the 32-bit version
of the BIOCSRTIMEOUT cookie. Given that struct timeval50 is
struct timeval50 {
long tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
BIOCSORTIMEOUT is *NOT* the 32-bit BIOCSRTIMEOUT cookie, so it appears that a
64-bit kernel will *NOT* handle a BIOCSRTIMEOUT from 32-bit userland, so any
32-bit program that uses a libpcap built 32-bit on NetBSD with a 64-bit time_t
will not work (that includes, but is not necessarily limited to, tcpdump).
Fixing that will require defining, on a 64-bit kernel, an ioctl cookie with the
codes for BIOCSRTIMEOUT and with the size of a 48-bit struct timeval, and
putting into bpf_ioctl() a case for that cookie that handles the 48-bit struct
timeval argument. (The same should be done for BIOCGRTIMEOUT; with the
possible exception of BIOCGETIF and BIOCSETIF, it looks as if the other BPF
ioctls have the same in-memory arguments in 32-bit and 64-bit mode.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
