| Message ID | 1432246737-27125-1-git-send-email-laurent@vivier.eu |
|---|---|
| State | New |
| Headers | show |
On 21 May 2015 at 23:18, Laurent Vivier <laurent@vivier.eu> wrote: > When executing a 64bit target chroot on 64bit host, > the ioctl() command can mismatch. > > It seems the previous commit doesn't solve the problem in > my case: > > 9c6bf9c7 linux-user: Fix ioctl cmd type mismatch on 64-bit targets > > For example, a ppc64 chroot on an x86_64 host: > > bash-4.3# ls > Unsupported ioctl: cmd=0x80087467 > Unsupported ioctl: cmd=0x802c7415 > > The origin of the problem is in syscall.c:do_ioctl(). > > static abi_long do_ioctl(int fd, abi_long cmd, abi_long arg) > > In this case (ppc64) abi_long is long (on the x86_64), and > > cmd = 0x0000000080087467 > > then > if (ie->target_cmd == cmd) > > target_cmd is int, so target_cmd = 0x80087467 > and to compare an int with a long, the sign is extended to 64bit, > so the comparison is: > > if (0xffffffff80087467 == 0x0000000080087467) > > which doesn't match whereas it should. > > This patch uses abi_int in the case of the target command type > instead of abi_long (and for consistency, update IOCTLEntry). > abi_int is really only needed in guest-layout structure declarations, since it has alignment attributes but is otherwise guaranteed to be an int32_t (and we assume all over the place that int is 32 bits, so int is ok too). So it's unnecessary in the function prototypes, and I think actively harmful in the IOCTLEntry struct (since that struct is not a shared-with-guest one). I think also the do_ioctl_fn() prototype and all the do_ioctl_* functions which are of that type need to have the cmd parameter switched from abi_long. This avoids potentially running into the same problem inside a do_ioctl function if it does comparisons on the cmd. thanks -- PMM
diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 1622ad6..68801cf 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -3293,8 +3293,8 @@ typedef abi_long do_ioctl_fn(const IOCTLEntry *ie, uint8_t *buf_temp, int fd, abi_long cmd, abi_long arg); struct IOCTLEntry { - int target_cmd; - unsigned int host_cmd; + abi_int target_cmd; + int host_cmd; const char *name; int access; do_ioctl_fn *do_ioctl; @@ -3849,7 +3849,7 @@ static IOCTLEntry ioctl_entries[] = { /* ??? Implement proper locking for ioctls. */ /* do_ioctl() Must return target values and target errnos. */ -static abi_long do_ioctl(int fd, abi_long cmd, abi_long arg) +static abi_long do_ioctl(int fd, abi_int cmd, abi_long arg) { const IOCTLEntry *ie; const argtype *arg_type;
When executing a 64bit target chroot on 64bit host, the ioctl() command can mismatch. It seems the previous commit doesn't solve the problem in my case: 9c6bf9c7 linux-user: Fix ioctl cmd type mismatch on 64-bit targets For example, a ppc64 chroot on an x86_64 host: bash-4.3# ls Unsupported ioctl: cmd=0x80087467 Unsupported ioctl: cmd=0x802c7415 The origin of the problem is in syscall.c:do_ioctl(). static abi_long do_ioctl(int fd, abi_long cmd, abi_long arg) In this case (ppc64) abi_long is long (on the x86_64), and cmd = 0x0000000080087467 then if (ie->target_cmd == cmd) target_cmd is int, so target_cmd = 0x80087467 and to compare an int with a long, the sign is extended to 64bit, so the comparison is: if (0xffffffff80087467 == 0x0000000080087467) which doesn't match whereas it should. This patch uses abi_int in the case of the target command type instead of abi_long (and for consistency, update IOCTLEntry). Signed-off-by: Laurent Vivier <laurent@vivier.eu> --- linux-user/syscall.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)