Why does dumpfile contain prctl, write, geteuid at beginning?

Daniel Näslund dannas at dannas.name
Mon Mar 2 12:08:54 PST 2015


Hi,

[ Had troube understanding why every tracefile contains prctl, write and
geteuid calls before execve. Starting writing this mail to ask but
found the answer in the code. Posting it anyway, perhaps someone else
can benefit from it. ]

Created a minimal program..

    $ cat > empty.s
    _start:
        mov $42,%rdi
        mov $0x3c, %eax
        syscall

    $ gcc -Wall empty.s -nostdlib

.. Two syscalls...

    $ strace ./empty
    execve("./empty", ["./empty"], [/* 66 vars */]) = 0
    _exit(42)                               = ?
    +++ exited with 42 +++

.. But why does the dump file contain prctl, write and geteuid calls?

    $ rr record ./empty
    $ rr dump | grep global_time
    global_time:1,   event:`SYSCALL:  prctl'      (state:0),  tid:4866,  ticks:4
    global_time:2,   event:`SYSCALL:  prctl'      (state:1),  tid:4866,  ticks:4
    global_time:3,   event:`SYSCALL:  write'      (state:0),  tid:4866,  ticks:472
    global_time:4,   event:`SYSCALL:  write'      (state:1),  tid:4866,  ticks:472
    global_time:5,   event:`SYSCALL:  geteuid'    (state:0),  tid:4866,  ticks:703
    global_time:6,   event:`SYSCALL:  geteuid'    (state:1),  tid:4866,  ticks:703
    global_time:7,   event:`SYSCALL:  geteuid'    (state:0),  tid:4866,  ticks:705
    global_time:8,   event:`SYSCALL:  geteuid'    (state:1),  tid:4866,  ticks:705
    global_time:9,   event:`SYSCALL:  geteuid'    (state:0),  tid:4866,  ticks:707
    global_time:10,  event:`SYSCALL:  geteuid'    (state:1),  tid:4866,  ticks:707
    global_time:11,  event:`SYSCALL:  geteuid'    (state:0),  tid:4866,  ticks:709
    global_time:12,  event:`SYSCALL:  geteuid'    (state:1),  tid:4866,  ticks:709
    global_time:13,  event:`SYSCALL:  execve'     (state:0),  tid:4866,  ticks:2153
    global_time:14,  event:`SYSCALL:  execve'     (state:0),  tid:4866,  ticks:0
    global_time:15,  event:`SYSCALL:  execve'     (state:1),  tid:4866,  ticks:0
    global_time:16,  event:`SYSCALL:  exit'       (state:0),  tid:4866,  ticks:0
    global_time:17,  event:`EXIT'     (state:0),  tid:4866,   ticks:0

After rr has forked the tracee, but before the execve call is made, it
sets up the secomp filter; writes some dummy data and uses geteuid calls
for finding a bug.

Snippets from the code:

    Task::spawn(...)
        // Signal to tracer that we're configured.
        ::kill(getpid(), SIGSTOP);

        set_up_seccomp_filter()
            prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER,...)

        // We do a small amount of dummy work here to retire
        // some branches in order to ensure that the ticks value is
        // non-zero.  The tracer can then check the ticks value
        // at the first ptrace-trap to see if it seems to be
        // working.
        // ...
        syscall(SYS_write, -1, &sum, sizeof(sum));

        CPUIDBugDetector::run_detection_code();
            // Call cpuid_loop to generate trace data we can use to detect
            // the cpuid rcb undercount bug. This generates 4 geteuid
            // calls which should have 2 rcbs between each of the
            // 3 consecutive pairs.
            cpuid_loop(4);
    }

Thanks,
Daniel


More information about the rr-dev mailing list