Re: clone flags

[Eric Paris <eparis@redhat.com>]

On Thu, 2007-07-19 at 09:24 -0400, John D. Ramsdell wrote:

> [root@goo fork]# ausearch -i -p 1160 > autrace.txt
> [root@goo fork]# grep clone strace.txt 
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7efb708) = 1122
> [root@goo fork]# grep clone autrace.txt 
> type=SYSCALL msg=audit(07/19/2007 09:16:02.350:848) : arch=i386 syscall=clone success=yes exit=1161 a0=1200011 a1=0 a2=0 a3=0 items=0 ppid=1158 pid=1160 auid=ramsdell uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 comm=fork exe=/home/ramsdell/proj/fork/fork subj=user_u:system_r:unconfined_t:s0 key=(null) 

Actually it's a problem with mapping things.  The flags are in a0.  If
you look at the clone man page they talk about sys_clone at the bottom
(which is the actual call, whereas cone is just a library function on
top of the call) and they state the the ordering for sys_clone is
different.  The kernel function is actually

asmlinkage long
sys_clone(unsigned long clone_flags, unsigned long newsp,
          void __user *parent_tid, void __user *child_tid, struct
pt_regs *regs)

So the flags are actually coming in the first argument.  To verify check

#define CLONE_CHILD_SETTID   0x01000000
#define CLONE_CHILD_CLEARTID 0x00200000
#define SIGCHLD              0x00000011

Which just so happens to be  0x01200011
and a0 just so happen to be     1200011

But it's just a difference between the library call 'clone' that the
application makes and the actual syscall glibc translates that to
sys_clone and the ordering of the flags.

-Eric