[CRIU] ARM: SIGSEGV in parasite code

[Alexander Kartashov]

On 06/13/2013 01:17 PM, Chanho Park wrote:
> (gdb) i r
> r0             0x4	4
> r1             0xb6f57424	3069539364
> r2             0xc	12
> r3             0x0	0
> r4             0x0	0
> r5             0x0	0
> r6             0xbea98b80	3198782336
> r7             0xbea98b60	3198782304
> r8             0x0	0
> r9             0x0	0
> r10            0x0	0
> r11            0x0	0
> r12            0x3	3
> sp             0xb6f57418	0xb6f57418
> lr             0xb6f531c8	-1225444920
> pc             0xb6f53084	0xb6f53084
> cpsr           0x20000010	536870928
> (gdb) x /10i $pc - 32
>     0xb6f53064:	str	r4, [sp, #4]
>     0xb6f53068:	bl	0xb6f54a60
>     0xb6f5306c:	cmp	r0, #12
>     0xb6f53070:	mov	r12, r0
>     0xb6f53074:	bne	0xb6f530a0
>     0xb6f53078:	add	r2, sp, #12
>     0xb6f5307c:	ldr	r1, [pc, #80]	; 0xb6f530d4
>     0xb6f53080:	mov	r0, #4
> => 0xb6f53084:	ldm	r2, {r2, r3, r12}
>     0xb6f53088:	add	r1, pc, r1

Take a look at the full routine disassembly:

    0xb6f53030:    push    {r4, lr}
    0xb6f53034:    sub    sp, sp, #24
    0xb6f53038:    ldr    r3, [pc, #144]    ; 0xb6f530d0
    0xb6f5303c:    mov    r4, #0
    0xb6f53040:    str    r1, [sp, #20]
    0xb6f53044:    mov    r2, #12
    0xb6f53048:    ldr    r12, [pc, r3]
    0xb6f5304c:    add    r1, sp, r2
    0xb6f53050:    str    r0, [sp, #12]
    0xb6f53054:    mov    r3, r4
    0xb6f53058:    str    r0, [sp, #16]
    0xb6f5305c:    mov    r0, r12
    0xb6f53060:    str    r4, [sp]
    0xb6f53064:    str    r4, [sp, #4]
    0xb6f53068:    bl    0xb6f54a60
    0xb6f5306c:    cmp    r0, #12
    0xb6f53070:    mov    r12, r0
    0xb6f53074:    bne    0xb6f530a0
    0xb6f53078:    add    r2, sp, #12
    0xb6f5307c:    ldr    r1, [pc, #80]    ; 0xb6f530d4
    0xb6f53080:    mov    r0, #4
=> 0xb6f53084:    ldm    r2, {r2, r3, r12}
    0xb6f53088:    add    r1, pc, r1
    0xb6f5308c:    str    r12, [sp]
    0xb6f53090:    bl    0xb6f53f38
    0xb6f53094:    mov    r0, r4
    0xb6f53098:    add    sp, sp, #24
    0xb6f5309c:    pop    {r4, pc}

    0xb6f530a0:    ldr    r1, [pc, #48]    ; 0xb6f530d8
    0xb6f530a4:    mov    r0, #1
    0xb6f530a8:    ldr    r2, [pc, #44]    ; 0xb6f530dc
    0xb6f530ac:    movw    r3, #401    ; 0x191
    0xb6f530b0:    add    r1, pc, r1
    0xb6f530b4:    str    r12, [sp]
    0xb6f530b8:    add    r2, pc, r2
    0xb6f530bc:    mov    r12, #12
    0xb6f530c0:    str    r12, [sp, #4]
    0xb6f530c4:    bl    0xb6f53f38
    0xb6f530c8:    mvn    r0, #0
    0xb6f530cc:    b    0xb6f53098


There's something terribly wrong: R2 must be SP + 12
since all paths containing the instruction ldm    r2, {r2, r3, r12} (at 
0xb6f53084)
goes through the instruction add r2, sp, 12 (at 0xb6f53078)
SP is 0xb6f57418 in the dump so it's difficult to explain
why R2 is 0x0c. However, the only thing that might have
corrupted the register SP is the routine at 0xb6f54a60:

    0xb6f54a60:    push    {r4, r5, r7}
    0xb6f54a64:    ldr    r4, [sp, #12]
    0xb6f54a68:    ldr    r5, [sp, #16]
    0xb6f54a6c:    movw    r7, #290    ; 0x122
    0xb6f54a70:    svc    0x00000000
    0xb6f54a74:    pop    {r4, r5, r7}
    0xb6f54a78:    bx    lr

that is a wrapper for the syscall sys_sendto()
as you've pointed out.

A new idea has come to me recently: we break stack alignment
in an odd-argument syscall wrapper that may be fatal for some
ARM platforms. Could you please do the following:

* reproduce the issue with the attached patch applied;
* reproduce the issue with with optimization disabled (compile
    crtools with the DEBUG=1 environment variable)?

-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dont-misalign-stack-in-syscall-wrapper.patch
Type: text/x-patch
Size: 816 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/343cf1af/attachment.bin>