On Wednesday, June 29, 2016 11:58:38 AM CEST Albert ARIBAUD wrote:
== IOCTLs and Y2038 ==
Some Linux IOCTLs may be Y2038-unsafe, or use types defined by glibc that do not match the kernel internal types. Known important cases are:
An ioctl command number is defined using the _IOR/_IOW/_IORW macros by the kernel with a structure whose size changes based on glibc's time_t. The kernel can handle these transparently by implementing handlers for both command numbers with the correct structure format.
The binary ABI changes based on the glibc time_t type, but the command number does not change. In this case, the kernel header files defining the data structure will check the "__USE_TIME_BITS64" macro [do we need a new macro for the kernel headers?] to provide a different command number for the new data structure layout. glibc will define this macro at an appropriate location [where?] to make it visible before including kernel header files.
An ioctl command passes time information in a structure that is not based on time_t but another integer type that does not get changed. The kernel header files will provide both a new structure layout and command number when "__USE_TIME_BITS64" is set.
[I can find examples for ioctl commands in each of those categories if needed.]
Please do -- I understand the first two cases, but I am not sure I understand the third one.
a) include/linux/ppdev.h:
/* Set and get port timeout (struct timeval's) */ #define PPGETTIME _IOR(PP_IOCTL, 0x95, struct timeval) #define PPSETTIME _IOW(PP_IOCTL, 0x96, struct timeval)
b) include/linux/lp.h: (this passes a timeval as well) #define LPSETTIMEOUT 0x060f /* set parport timeout */
c) Actually I could not find a real case any more, it's possible they are all gone. Two similar cases though:
linux/raid/md_u.h: (this one was "fixed" by ensuring the user space side can deal with 32-bit time stamps)
typedef struct mdu_array_info_s { ... unsigned int utime; /* 0 Superblock update time */ ... } mdu_array_info_t; #define GET_ARRAY_INFO _IOR (MD_MAJOR, 0x11, mdu_array_info_t)
drivers/staging/ft1000/ft1000-usb/ft1000_ioctl.h: (this file was removed since, as the hardware is now obsolete)
struct IOCTL_GET_DSP_STAT { unsigned char DspVer[DSPVERSZ]; /* DSP version number */ unsigned char HwSerNum[HWSERNUMSZ]; /* Hardware Serial Number */ unsigned char Sku[SKUSZ]; /* SKU */ unsigned char eui64[EUISZ]; /* EUI64 */ unsigned short ConStat; /* Connection Status */
unsigned long nTxPkts; /* Number of packets transmitted * from host to dsp */ unsigned long nRxPkts; /* Number of packets received from * dsp to host */ unsigned long nTxBytes; /* Number of bytes transmitted * from host to dsp */ unsigned long nRxBytes; /* Number of bytes received from * dsp to host */ unsigned long ConTm; /* Current session connection time * in seconds */ .... } __packed;
#define IOCTL_FT1000_GET_DSP_STAT _IOR(FT1000_MAGIC_CODE, \ IOCTL_GET_DSP_STAT_CMD, \ struct IOCTL_GET_DSP_STAT)
== Socket options ==
Like ioctl(), setsockopt()/getsockopt() has a few interfaces that are passing time data:
SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING: These enable the timestamping infrastructure for a socket, which will consecutively return data to user space using "cmsg" data on the socket. The kernel does not know the layout of 'struct timespec' and 'struct timeval' when filling the cmsg data, so we need to define new binary values for the three flags, which then get used if __USE_TIME_BITS64 is set.
IOW, introduce three new optname values (say 51, 52, and 53 as on my machine, /usr/include/asm-generic/socket.h stops at 50 right now) that would behave similar to options 29, 35 and 37 but would use Y2038-safe timestamps; and define option names SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING to be either 29, 35 and 37 (the Y2038-unsafe options) or 51, 52 and 53 (the Y2038-safe ones) depending on __USE_TIME_BITS64. Right?
Correct.
SO_RCVTIMEO/SO_SNTTIMEO: These pass a 'struct timeval' and a length. Assuming that the 'optlen' argument of the setsockopt syscall always matches the size of 'struct timeval', the kernel will be able to access the data in the same format that was passed by glibc. [alternatively, we could handle this the same way as SO_TIMESTAMP*, using new numbers for the flags].
I would prefer new numbers, that's more explicit and slightly safer, as if we rely on optlen, Murphy's Law will see to it that in practice it will have the wrong value.
Fair enough.
Arnd