Post by bob prohaskaAfter a successful compile of audio/xoscope on a Pi4 running current a
stream of messages appeared on the console and in the security log
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045006
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045005
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045002
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045006
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045005
+WARNING pid 26370 (xoscope): ioctl sign-extension ioctl ffffffffc0045002
They seem to come at a fairly high rate and clutter the logfiles, but
apart from that nuisance nothing else seemed visibly amiss.
Are they of any significance?
The code from a mid 2021-Mar vintage of main [so: 14]
looks like:
/* ARGSUSED */
int
sys_ioctl(struct thread *td, struct ioctl_args *uap)
{
u_char smalldata[SYS_IOCTL_SMALL_SIZE] __aligned(SYS_IOCTL_SMALL_ALIGN);
uint32_t com;
int arg, error;
u_int size;
caddr_t data;
#ifdef INVARIANTS
if (uap->com > 0xffffffff) {
printf(
"WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n",
td->td_proc->p_pid, td->td_name, uap->com);
}
#endif
com = (uint32_t)uap->com;
. . .
where sys/sys/sysproto.h shows:
struct ioctl_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char com_l_[PADL_(u_long)]; u_long com; char com_r_[PADR_(u_long)];
char data_l_[PADL_(char *)]; char * data; char data_r_[PADR_(char *)];
};
So, uap->com is unsigned with 64 bits for aarch64 and the
0xffffffff is converted to match that for the > test (C
rules).
The assignment to uint32_t com would end up with a
truncated value recorded whenever the warning is
produced.
Thus a value like 0xffffffffc0045006ul ends up with
com == 0xc0045006u instead.
Then looking at the usage of com leads to sys/sys/ioccom.h :
. . .
/*
* Ioctl's have the command encoded in the lower word, and the size of
* any in or out parameters in the upper word. The high 3 bits of the
* upper word are used to encode the in/out status of the parameter.
*
* 31 29 28 16 15 8 7 0
* +---------------------------------------------------------------+
* | I/O | Parameter Length | Command Group | Command |
* +---------------------------------------------------------------+
*/
#define IOCPARM_SHIFT 13 /* number of bits for ioctl size */
#define IOCPARM_MASK ((1 << IOCPARM_SHIFT) - 1) /* parameter length mask */
#define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK)
#define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16))
#define IOCGROUP(x) (((x) >> 8) & 0xff)
#define IOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */
#define IOC_VOID 0x20000000UL /* no parameters */
#define IOC_OUT 0x40000000UL /* copy out parameters */
#define IOC_IN 0x80000000UL /* copy in parameters */
#define IOC_INOUT (IOC_IN|IOC_OUT)/* copy parameters in and out */
#define IOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for IN/OUT/VOID */
. . .
So, com == 0xc0045006u ends up with:
I/O matching: : IOC_IN | IOC_OUT
Command matching (byte): 0x06u
Command Group matching (byte): 0x50u
Parameter Length matching : 0x0004u
While I do not know the specifics for the command
and command group encoding, the truncated value
seems coherent with the code that is using it.
My guess would be xoscope used a signed 32-bit type
that got a value with sign extension to 64 bits
before the value started being treated as unsigned.
If it had used an unsigned type instead, the padding
would have been a zero fill instead (presuming that
I've guessed right).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)