Date: Mon, 25 Jun 2018 22:48:28 +0200 (CEST) From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz> To: owl-dev@...ts.openwall.com cc: Vasily Averin <vvs@...tuozzo.com> Subject: Re: 32-bit syscall breakage in -431 kernel with KAISER On Mon, 25 Jun 2018, Solar Designer wrote: > On Mon, Jun 25, 2018 at 07:29:42PM +0200, Pavel Kankovsky wrote: >> On Sun, 24 Jun 2018, Solar Designer wrote: >> >>> My preliminary analysis suggests that maybe the KAISER backport broke >>> the pt_regs ABI for 32-bit syscalls in x86_64 kernels. Specifically, >>> SIOCGIFCONF might be failing with EFAULT because fs/compat_ioctl.c: >>> dev_ifconf() uses compat_alloc_user_space(): >> >> Yes. It fails because compat_alloc_user_space returns NULL. > > Thanks! How exactly did you debug this, on which kernel/build? I made a fresh 3.1 installation into a vm and the rest was the old good if somewhat tedious method: I added a bunch of printk's to the function in question, rebuilt the kernel, installed it, rebooted and ran ifconfig extracted from the 32-bit version of Owl 3.1. (I know I should learn how to use builtin GDB server in Qemu but...) To get more information, I added show_regs(task_pt_regs(current)) to the beginning of dev_ifconf() and here is the result: CPU 0, VCPU 0:0 Modules linked in: vzethdev simfs exportfs vzdquota vznetdev vzmon vzdev Pid: 986, comm: ifconfig32 Tainted: P -------------------- 2.6.18-431.el5.028stab123.1.owl1xxx #1 028stab123 RIP: 0292:[<0000000000000073>] [<0000000000000073>] RSP: 007b:000000000000007b EFLAGS: bf98675c RAX: 0000000000008912 RBX: 0000000000000000 RCX: 00000000bf986774 RDX: 0000000000000004 RSI: 00000000bf986774 RDI: 0000000000000036 RBP: ffffffff80065a3e R08: 0000000000000036 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffffff805b2000(0033) knlGS:00000000b7e44a90 CS: 0060 DS: 007b ES: 007b CR0: 000000008005003b CR2: 00000000b7eab100 CR3: 000000003f808000 CR4: 00000000000006e0 Userland rsp seems to be 0x7b and this makes compat_alloc_user_space() fail. It seems to me the data are shifted: the value reported as "EFLAGS" looks like an actual userland stack pointer, "0000000000000073" should probably be CS rather than RIP (the offset) etc. -- Pavel Kankovsky aka Peak "Que sçay-je?"
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ