Re: pt_regs structure for sys_clone()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fernando. What I need is a way to fill out the pt_regs structure
itself with the same values that are in the pt_regs structure of the
currently running process. Let's say I have my own system call
sys_do_something(). So when I'm inside the kernel mode, an want to call
sys_clone() from within this new function I must put my_regs as
parameter to sys_clone().
So how to find out all the values the pt_regs must contain? For example
what could I do in the following code?

int sys_do_something() {
struct pt_regs my_regs;
my_regs.eax = ?
my_regs. ... ?
my_regs. ebp = ?
// and so on before calling
int ret = sys_clone(pt_regs);
}

I do not mean the system calls parameter only but all the values that
make it possible that the new created thread is able to be switched to
the next time the scheduler activates it. So far I get problems because
of "iret execption" or "bad eip" or "no vm86_info: bad". That's why I
suppose, that the values in the my_regs I give to sys_clone aren't valid
and that leads to problems when the context switch is made to this new
created thread.

Generally the problem is, that I do not know how to access all the
values that where saved for the currently running process before doing
my system call and as far as I know it's not possible to access all the
content of this structure from the task_struct structure of the current
process.
Therefore it would be nice to have something like: my_ptregs =
get_current_pt_regs(). I hope it's clearer now what my problem is.

Thank you for help.

Regards,
E.X.


On Do, 2006-05-25 at 18:21 +0200, Fernando Apesteguía wrote:
> AFAIK, you can get all the syscall parameters from pt_regs as follows:
> 
> int sys_close(struct pt_regs my_regs);
> 
> and inside sys_close:
> 
> regs.ebx or regs.eax
> 
> Parameters are passed into cpu registers. If you want to catch that
> information you should bridge the original address in the syscall
> table to point to a custom function and then call to the original
> function from the yours one. 
> 
> A cleaner solution for this is to use kprobes framework to keep track
> of the syscall parameters.
> 
> The parameters are passed in an ordered way (eax, ebx, ecx and so on).
> The first parameters is always the syscall number (__NR_* constants
> defined in unistd.h). Some syscalls needs more parameters. If this is
> the case, one of the parameters (sorry I forgot which one...) has a
> pointer to a memory address where the parameters are.
> 
> 
> 
> Best regards
> 
> 
> On 5/25/06, eax <tcpip@xxxxxxx> wrote:
>         Hi all.
>         Does anyone know how to get all the information a pt_regs
>         structure (as
>         parameter for the sys_clone() system call) must contain? I
>         know that
>         this structure contains the state of the user space processes
>         just 
>         before doing the system call, but how to fill it within kernel
>         mode? I
>         suppose there exists a function or a macro that returns such a
>         struct
>         for the current process, but all my efforts searching for
>         something like 
>         that were without success so far. Calling sys_clone() from
>         within the
>         kernel mode makes this neccessary I think.
>         
>         In addition I'm interested in something like a specification
>         for linux
>         system calls in general. For example how should I know how
>         sys_clone 
>         expects the child stack to be set up and so on. Is there such
>         a
>         document? After all the glibc developer suceeded implementing
>         all this,
>         so how did they know how to do it? :)
>         
>         Thank you all in advance.
>         
>         Regards,
>         E.X.
>         
>         
>         
>         
>         -----BEGIN PGP SIGNATURE-----
>         Version: GnuPG v1.4.3 (GNU/Linux)
>         
>         iEYEABECAAYFAkR1g5UACgkQhW3f3uMdmbF4ZgCg67ijyvIvYeRoQrtGuKdVSdsv
>         pQkAoM8bRMv975I3J+OGxY8tfjauMLQq
>         =mt3H
>         -----END PGP SIGNATURE-----
>         
>         
> 

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux