How can I get Command Line arguments of a process during do_fork?
Bill Last Name Omitted
I'm trying to determine how to read from memory:
1) the executable file name,
2) the command line arguments
3) and if possible the environment variables
of a recently forked process/thread in the linux kernel
(in the do_fork() function in kernel/fork.c)
I'm sure the kernel must track this information, but
I haven't determined what the preferred access
mechanism is.
I am using a linux kernel 2.5.43 (with the
Linux Trace Toolkit (LTT) release 0.9.6pre2
patch), with the i386 target architecture (AMD Athlon).
but I imagine that this should not substantially impact
where the command line parameters and executable name
are stored.
Thanks:
Bill M. (last name witheld to prevent spamming)
Basile STARYNKEVITCH
Bill> Hello All: I'm trying to determine how to read from memory:
Bill> 1) the executable file name, 2) the command line arguments
Bill> 3) and if possible the environment variables of a recently
Bill> forked process/thread in the linux kernel (in the do_fork()
Bill> function in kernel/fork.c) I'm sure the kernel must track
Bill> this information, but I haven't determined what the
Bill> preferred access mechanism is.
Why do you want to do this in kernel space?
In userland, you got all the information thru /proc
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Kasper Dupont
>
> I'm sure the kernel must track this information
It doesn't.
What the kernel does keep track of is:
Where was the argument list and environment at the
last execve call, and a handle for the executable.
The only time argument list and environment is well
defined is when execve() is being called. Otherwise
it is the programs own responsibility to handle it,
the kernel has no way to find it.
You can look at the memory location where it was
before, but you have no garantee what you are
going to find there.
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
Bill Last Name Omitted
> >>>>> "Bill" == Bill Last Name Omitted <fooli...@hotmail.com> writes:
>
> Bill> Hello All: I'm trying to determine how to read from memory:
> Bill> 1) the executable file name, 2) the command line arguments
> Bill> 3) and if possible the environment variables of a recently
> Bill> forked process/thread in the linux kernel (in the do_fork()
> Bill> function in kernel/fork.c) I'm sure the kernel must track
> Bill> this information, but I haven't determined what the
> Bill> preferred access mechanism is.
>
> Why do you want to do this in kernel space?
>
> In userland, you got all the information thru /proc
The data acquisition tool I'm working on (LTT) is compiled into the kernel,
and the application I'm doing it for involves auditing, more complete
information is generally preferred. The /proc file system has to get
its information from somewhere, so I'm wondering where that is.
The kernel may not directly track this information, but it must keep
a process table, and each process ought to have a way to query its
argument vector and environment variables. If the ps command in user
space can grab this information, I figured that I ought to be able to obtain
it in the kernel.
Regards:
Bill M.
Bill Last Name Omitted
> Bill Last Name Omitted wrote:
> >
> > I'm sure the kernel must track this information
>
> It doesn't.
>
> What the kernel does keep track of is:
> Where was the argument list and environment at the
> last execve call, and a handle for the executable.
This seems sensible, but I'm looking at struct task_struct in
the include/linux/sched.h (the similar 2.5.46 version can
be seen at:http://lxr.linux.no/source/include/linux/sched.h?v=2.5.46#L273)
but I haven't been able to figure out which field has these pointers.
The struct linux_binprm type, in particular the bprm variable in the
do_execve appears to have just the values I want in it, is there a way to
to query either the kernel or the process (task_struct) for that information.
> The only time argument list and environment is well
> defined is when execve() is being called. Otherwise
> it is the programs own responsibility to handle it,
> the kernel has no way to find it.
But the ps command can print out the command line arguments
of other processes. I imagine it does so by reading the /proc
file system (but haven't looked at the source for ps yet).
If the information is in the /proc file system, then there
must be a way that it got inserted into /proc, and a way
that it can be looked up after the exec has occurred, and
in the case of forked processes, the information must be inherited
or copied somehow from the parent. This is what I want to know.
I'm planning on logging sys_execve events as well.
> You can look at the memory location where it was
> before, but you have no garantee what you are
> going to find there.
It would be interesting to me to look and if it were corrupted, I'd want
to know that too.
Regards:
Bill M.
Mario Klebsch
>The /proc file system has to get
>its information from somewhere, so I'm wondering where that is.
Just look at the source code! You already identified, where to look
(code for /proc), you just need to do it.
73, Mario
--
Mario Klebsch ma...@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
enr...@arabia.nodomain
> But the ps command can print out the command line arguments
> of other processes. I imagine it does so by reading the /proc
> file system (but haven't looked at the source for ps yet).
> If the information is in the /proc file system, then there
> must be a way that it got inserted into /proc, and a way
> that it can be looked up after the exec has occurred, and
try to look in /usr/src/linux/fs/proc/base.c,
static int proc_pid_environ(struct task_struct *task, char * buffer)
and
static int proc_pid_cmdline(struct task_struct *task, char * buffer)
> It would be interesting to me to look and if it were corrupted, I'd want
> to know that too.
I cannot see how you can know that, except by some feeble heuristics.
Regards, Enrique
Bill Last Name Omitted
> fooli...@hotmail.com (Bill Last Name Omitted) writes:
> >The /proc file system has to get
> >its information from somewhere, so I'm wondering where that is.
>
> Just look at the source code! You already identified, where to look
> (code for /proc), you just need to do it.
Thanks Mario, however, I have already narrowed down my search space that
much already :-). I'm having fun learning kernel stuff as we go, so
the reading is not all in vain (although I've got other duties).
I've read a few modules already (about 20 or so) but I'm hoping to
prioritize my reading list.
It's been a while since I've done kernel programming, and this is my
first shot at Linux kernel programming. While I realize it isn't going
to be instant, books like Bovet and Cesanti are good intros, but for
what I'm doing, I want a few details not well covered there.
Regards:
Bill M.
Kasper Dupont
>
> Kasper Dupont <kas...@daimi.au.dk> wrote in message news:<3E25DE37...@daimi.au.dk>...
> > Bill Last Name Omitted wrote:
> > >
> > > I'm sure the kernel must track this information
> >
> > It doesn't.
> >
> > What the kernel does keep track of is:
> > Where was the argument list and environment at the
> > last execve call, and a handle for the executable.
>
> This seems sensible, but I'm looking at struct task_struct in
> the include/linux/sched.h (the similar 2.5.46 version can
> be seen at:http://lxr.linux.no/source/include/linux/sched.h?v=2.5.46#L273)
> but I haven't been able to figure out which field has these pointers.
They are in the struct mm_struct pointed to by the mm field:
http://lxr.linux.no/source/include/linux/sched.h?v=2.5.46#L173
As for the executable, I'm not sure where that is pointed to.
Look in the procfs source if you need to find out.
>
> > The only time argument list and environment is well
> > defined is when execve() is being called. Otherwise
> > it is the programs own responsibility to handle it,
> > the kernel has no way to find it.
>
> But the ps command can print out the command line arguments
> of other processes.
It prints the name of the process, which defaults to the
command line. But the process itself can change what is
visible with ps.
> I imagine it does so by reading the /proc
> file system (but haven't looked at the source for ps yet).
Yes /proc/%d/cmdline.
> the information must be inherited
> or copied somehow from the parent.
The mm_struct with the offsets is copied. The contents are
handled with CoW pages as everything else.
>
> It would be interesting to me to look and if it were corrupted, I'd want
> to know that too.
You cannot know if it were changed, unless you know what it
was before. And being changed doesn't have to mean it has
been corrupted, it could be changed intentionally to show
helpfull information in the ps output.
Mario Klebsch
>It's been a while since I've done kernel programming, and this is my
>first shot at Linux kernel programming. While I realize it isn't going
>to be instant, books like Bovet and Cesanti are good intros, but for
>what I'm doing, I want a few details not well covered there.
If you have to dig through a huge pile of unknown code (like the
kernel), have you ever tried cscope?
Bill Last Name Omitted
> fooli...@hotmail.com (Bill Last Name Omitted) wrote
> > But the ps command can print out the command line arguments
> > of other processes. I imagine it does so by reading the /proc
> > file system (but haven't looked at the source for ps yet).
> > If the information is in the /proc file system, then there
> > must be a way that it got inserted into /proc, and a way
> > that it can be looked up after the exec has occurred, and
>
> try to look in /usr/src/linux/fs/proc/base.c,
>
> static int proc_pid_environ(struct task_struct *task, char * buffer)
Thanks this is very helpful!
>
> and
>
> static int proc_pid_cmdline(struct task_struct *task, char * buffer)
This is good too!
> > It would be interesting to me to look and if it were corrupted, I'd want
> > to know that too.
>
> I cannot see how you can know that, except by some feeble heuristics.
Well, real corruption would be hard to detect, but it might be possible
to detect at least changes to the process name by logging execve invocations
and at other times during process creation, lifetime and termination.
Perhaps as I dig in a bit I'll get a better sense of what information
is available/useful and accurate.
Thanks for your help Enrique, it is much appreciated.
Regards:
Bill M.
Bill Last Name Omitted
> Bill Last Name Omitted wrote:
> >
> > Kasper Dupont <kas...@daimi.au.dk> wrote in message news:<3E25DE37...@daimi.au.dk>...
> > > Bill Last Name Omitted wrote:
> > > What the kernel does keep track of is:
> > > Where was the argument list and environment at the
> > > last execve call, and a handle for the executable.
> >
> > This seems sensible, but I'm looking at struct task_struct in
> > the include/linux/sched.h (the similar 2.5.46 version can
> > be seen at:http://lxr.linux.no/source/include/linux/sched.h?v=2.5.46#L273)
> > but I haven't been able to figure out which field has these pointers.
>
> They are in the struct mm_struct pointed to by the mm field:
> http://lxr.linux.no/source/include/linux/sched.h?v=2.5.46#L173
>
> As for the executable, I'm not sure where that is pointed to.
> Look in the procfs source if you need to find out.
Thanks for the pointer. Your help is much appreciated.
> > > The only time argument list and environment is well
> > > defined is when execve() is being called. Otherwise
> > > it is the programs own responsibility to handle it,
> > > the kernel has no way to find it.
I'm not being precise, the tool I'm working with is compiled into the
Kernel (that is the only way to intercept system calls, since the
system call vector is no longer accessible at run time, probably a good
thing from a security perspective). So while the information may
not strictly speeking be in userspace, to capture it at the points
of interest inolves developing a bit of kernel software to instrument
the system calls.
> > But the ps command can print out the command line arguments
> > of other processes.
>
> It prints the name of the process, which defaults to the
> command line. But the process itself can change what is
> visible with ps.
This seems right, because if I understand you this information
resides in the processes user space.
> > I imagine it does so by reading the /proc
> > file system (but haven't looked at the source for ps yet).
>
> Yes /proc/%d/cmdline.
Thanks, that is a nice thing to know.
> > the information must be inherited
> > or copied somehow from the parent.
>
> The mm_struct with the offsets is copied. The contents are
> handled with CoW pages as everything else.
This also makes sense.
> >
> > It would be interesting to me to look and if it were corrupted, I'd want
> > to know that too.
>
> You cannot know if it were changed, unless you know what it
> was before. And being changed doesn't have to mean it has
> been corrupted, it could be changed intentionally to show
> helpfull information in the ps output.
Corrupted is perhaps the wrong word, but it might be harder to undetectably
change a processes name and command line information if the execve parameters
are logged and compared against information acquired during other points of
a process's life cycle.
Regards:
Bill M.