This is the mail archive of the
mailing list for the glibc project.
- From: "Andreas Ames" <Andreas dot Ames at gmx dot de>
- To: libc-help at sourceware dot org
- Date: Mon, 13 May 2013 13:07:47 +0200 (CEST)
- Subject: Intercept ioctls
- Sensitivity: Normal
I have to tame a library that I can't change the source code of (although I have it). Therefore I need to shim glibc's ioctl function. This is a little bit special as glibc's ioctl is declared with ellipsis. Although I'd prefer a portable solution the minimum requirements for the shim are to be functional on i386 an 32bit PowerPC architectures. I'd appreciate if you could help me with the following issues.
The examples intercepting ioctl that I can find in the web forward the ioctl call with a third argument of type 'void*' like the following:
int ioctl(int fd, int request, ...)
argp = va_arg(args, void*); /* Is that really safe? */
res = (*real_libc_ioctl)(fd, request, argp);
/* do my specific stuff here */
What I'm concerned about is whether it's 'safe' enough to use a void* argument here. For instance, I know there are ioctls like TIOCSBRK or TIOCCBRK that don't expect any argument. My guess is that the above shim would be functional at least on the relevant architectures with no-third-argument ioctls:
* On i386 the above shim would read something arbitrary from the stack and use it as argp. Given that a ioctl call on the top of the stack is impossible (I think) this would be ugly but probably non-fatal.
* If I remember correctly PowerPC uses CPU registers for argument passing; given that three four byte wide arguments should certainly fit into the registers, I'd think this should also be ugly but non-fatal.
My questions are:
1. Is my above guesswork reasonable?
2. Are there other argument types that are more dangerous (like one-byte, two-byte etc. arguments)?
3. Do you know a better approach to shim ioctls?
Thanks in advance,