Re: clone flags
On Thu, 2007-07-19 at 14:45 -0400, John D. Ramsdell wrote:
Eric Paris <eparis(a)redhat.com> writes:
> Actually it's a problem with mapping things. The flags are in a0.
Eric, you seem to have nailed this issue.
I played around with tracing the clone system call, and found
something else since my last message. I traced a program that creates
threads within a single address space with clone, and that call puts
the clone flags into a2. The auparse library interprets these flags
as one would expect.
Actually, not quite. Its still the same mapping problem. auparse is
busted and the flags are always in a0 for the audit log. auparse is
actually giving you total and complete crap output. Notice in auparse
you got a long list of flags.
CLONE_VM|CLONE_FS|CLONE_SIGHAND|CLONE_PTRACE|CLONE_PARENT|CLONE_THREAD|
CLONE_NEWNS|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_CHILD_CLEARTID|
CLONE_DETACHED|CLONE_UNTRACED|CLONE_CHILD_SETTID|CLONE_STOPPED|
CLONE_NEWUTS
And the strace output below only showed a short list of flags. Also
note that one is NOT a sub/super set of the other. CLONE_DETACHED above
and CLONE_FILES below?
CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|
CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
Anyway I took the strace flags and worked it out:
#define CLONE_VM 0x00000100
#define CLONE_FS 0x00000200
#define CLONE_FILES 0x00000400
#define CLONE_SIGHAND 0x00000800
#define CLONE_THREAD 0x00010000
#define CLONE_SYSVSEM 0x00040000
#define CLONE_SETTLS 0x00080000
#define CLONE_PARENT_SETTID 0x00100000
#define CLONE_CHILD_CLEARTID 0x00200000
0x003D0F00
Low and behold the audit a0 is 3d0f00
Looks like auparse was wrongly trying to convert the pointer for
parent_tidptr=0xb7f7fbd8 (notice we had CLONE_PARENT_SETTID set) into
clone flags and that list of flags was the best it could do.
So I'd say change all your stuff to look only at a0 for clone and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.
-Eric