[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1806252211240.30595@argo.troja.mff.cuni.cz>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
