International Journal of Computer Engineering & Technology ... · International Journal of Computer Engineering & Technology (IJCET) Volume 8, Issue 4 , July -August 2017 , pp. 1

http://www.iaeme.com/IJCET/index.asp 1 [email protected]

International Journal of Computer Engineering & Technology (IJCET) Volume 8, Issue 4, July-August 2017, pp. 1–11, Article ID: IJCET_08_04_001 Available online at http://www.iaeme.com/ijcet/issues.asp?JType=IJCET&VType=8&IType=4 Journal Impact Factor (2016): 9.3590(Calculated by GISI) www.jifactor.com ISSN Print: 0976-6367 and ISSN Online: 0976–6375 © IAEME Publication

PROCESS FORENSIC FOR FAST ENTRY SYSTEM CALLS

Narayan A. Joshi Professor, Parul University, Vadodara, India

Darshan B. Choksi Professor, G H Patel PG Department of Computer Science & Technology,

Sardar Patel University, India

Akash N. Soni Systems Engineer, Automation group, Infosys Limited, Bangalore, India

ABSTRACT The process forensics and process state checkpointing mechanisms have always

remained challenging for ever changing processor architectures. Process forensics is one of the significant foundation mechanisms for process control and management such as process migration and process checkpoint-restart. The Dynamic process migration and process forensic mechanisms require dynamic state checkpointing of the desired process. At the time of process forensics and process state checkpointing, the process could be running in some system call. Present kernels are adopting sysenter instruction based fast mechanism for system call invocation for present processor architectures. There is an extreme need for availability of open source mechanism for dynamic investigation of system call on present kernels for contemporary architectures. This paper presents a novel kernel-level and open source mechanism for investigating sysenter instruction-based fast entry system calls. Key word: Process forensic, process checkpointing, process investigation, sysenter, system call, kernel, Linux, process migration. Cite this Article: Narayan A. Joshi, Darshan B. Choksi and Akash N. Soni, Process Forensic for Fast Entry System Calls. International Journal of Computer Engineering & Technology, 8(4), 2017, pp.1–11. http://www.iaeme.com/ijcet/issues.asp?JType=IJCET&VType=8&IType=4

1. INTRODUCTION Advancements in processor architectures and bus technology is reframing not only the way of representing processes and but also the technique for invoking system calls in present Linux kernels. For example, to achieve better performance on present processor architectures, the Linux kernel has started adopting an alternative approach of fast system call invocation in place of the older one which is based on software interrupt [2]. However, such a revolution in system call invocation technique has triggered substantial modifications to relevant process

Narayan A. Joshi, Darshan B. Choksi and Akash N. Soni


control and management mechanisms. Several kernel-level techniques such as dynamic process migration, process forensics, process checkpoint-restart and process state investigation are examples of the runtime process control and management mechanisms. Identification of the exact system call which is being currently run by a particular process which is under observation is one of many key requirements of such mechanisms. Such applications are expected to work in robust way too. A novel, kernel-level and open source approach for investigating fast entry system calls is presented in this paper.

Our contributions are summarized below: The authors have suggested a kernel-level approach to determine whether a particular partially

executed process is currently running in some system call or not.

The authors have detected the system call if the process to be investigated is running in system call.

The authors have shown effectiveness of our suggested mechanism by experimenting the mechanism on various processes which are currently running in system call.

The authors have shown effectiveness of our suggested mechanism by experimenting the mechanism on various processes which are currently not running in any system call.

The suggested kernel-level mechanism is applicable to present faster way of system call invocation which is based on special CPU-instructions sysenter and sysexit.

2. MOTIVATION In line with [4], various process control and management related requirements and applications such as - process forensic, dynamic process migration, process checkpoint-restart and process investigation - are keenly concerned with determination of the current dynamic state of a particular process.

Kernel-level dynamic process migration mechanism involves runtime migration of a partially executed process from its originating workstation to some other workstation in distributed system. There are numerous substantial advantages of kernel-level dynamic process migration: fault tolerance, load balancing, resource utilization in cloud and power backup [13]. In distributed systems, workstation-overloading problem can be solved with help of load balancing solution which can be achieved by migrating processes from highly loaded workstations to lightly loaded workstations or idle workstations [3]. During partial machine failure, particular process which is required to be rescued can be shifted to some stable workstation with help of dynamic process migration and thereby serve fault tolerance. Moreover, in cloud environments, resource utilization may be attained by migrating processes from resource lacking virtual machine to resource-rich virtual machine. Similarly resource hungry process can be moved from its originating poor-resourced workstation to some wealthy resource workstation with the help of dynamic process migration [14].

The dynamic process migration mechanism including other process management applications, involve identification of current state of the process which is to be migrated among workstations [21]. The process state identification phase involves determination of static and dynamic state information of the desired process which is to be shifted from its source workstation to some remote workstation. Determination of dynamic process state information involves identification of processor register context, received signals information, pending signals information, address space details, information relevant to received interrupts, I/O context, user credentials and system calls [18].

At the time of process migration, if the desired process is running in some system call, then the migration mechanism must ensure that after migrating to the remote workstation,

Process Forensic for Fast Entry System Calls


execution of the migrated process must resume from within the same system call in which it was executing just before migration took place. If such a care is not taken, then the migrated process would not behave consistently and it would fail in serving its actual objective. Such execution inconsistency after migrating to the destination workstation may lead the workstation towards entire system crash.

Likewise, the kernel-level process forensic and process checkpoint-restart mechanisms, do involve identification of dynamic state information of a process to be investigated. Such mechanisms too are supposed to exactly determine about a particular system call in which the desired process could be running at the time of their application on the process.

Hence, identification of system call information being run by a particular process has become an important and mandatory task for the process control and management applications. And therefore, an appropriate kernel-level mechanism is strongly required to be established which can assist the above listed class of kernel-level applications and circumstances.

3. THE PROBLEM As described in [15] and [8], the Linux kernel-level process descriptor ‘struct task_struct’ maintains information about wide range of dynamic state aspects of a process such as user credentials, processor register context, information about received & pending signals, memory context, file context and I/O context.

However, information related to a system call being presently executed by a user-level process is not maintained in the Linux process descriptor. Furthermore, the present kernel versions deployed on the Pentium II and onwards processors use the sysenter-based fast system call invocation technique for realizing better performance. But the kernel, in the process descriptor, doesn’t maintain information related to sysenter-based fast system call invocation technique. In addition, availability of a kernel-level facility is lacking for determination about whether a process is running in some system call invoked through sysenter-based kernel-level entry mechanism is lacking.

Hence, a kernel-level mechanism is desired to be established, which helps its users to determine whether a particular process is currently running in some system call or not. If the process is currently in some system call, then the mechanism should give information about the system call the process is running in.

In this paper, a novel solution mechanism is presented to meet the above listed problem requirement.

4. RELATED WORK Several utilities including strace, gdb, ptrace, ktrace, ltrace and dtrace were studied. These are well-known and powerful utilities available in various Linux environments.

The GNU debugger gdb [6], is extensively used and potential user-level debugging utility that allows to see what is going on ‘inside’ another process. However, to gain its benefits, one has to launch the debugger gdb first, and then only a desired program can be studied. Without pre-launching gdb and without initiating a process inside the gdb well in advance, it is not suitable to investigate system call aspect of a process which is to be investigated. The strace [19] is a widely used and very influential diagnostic and instructional tracing technique. It is a user level system call tracer which prints out a trace of all the system calls made by a process. But, it requires an explicit interrupt signal for detaching itself from the process to be investigated. As well, the class of kernel-level process



management and control mechanisms, do require an automated and straightforward mechanism that does not require explicit attachment to and detachment from the process to be investigated.

With ltrace [10], like gdb, the process is required to be started using ltrace user level command. However, at runtime, if it is attached to a running process, it does not reflect the system call details if the process to be migrated is currently running in some system call, for example the read() system call. The ptrace()[16], it is a system call that enables one user level process to control execution of another. Its PTRACE_SYSCALL makes the child process to be investigated to stop after the next system call. Though it is a very powerful system call, it requires continuous monitoring of a process to be investigated. The dtrace [5] is a comprehensive dynamic tracing framework by defining probe points on the fly. Though it can trace entry and exit of each system call made by a process, it is not appropriate for kernel level process control and management mechanisms to use in kernel level at particular times. The ktrace utility [7] enables kernel trace logging for a particular process, though it requires setting of trace points for system calls.

A process investigation mechanism involving system call forensics has been suggested in [12]. With help of the technique suggested in [12], a load balancing solution has been demonstrated in [13]. Likewise, [14] has demonstrated the dynamic process migration with help of the technique suggested in [12] in cloud computing environment. However, the algorithm suggested in [12] is limited for older way of system call invocation mechanism based on CPU-mode switching using software interrupt.

An implementation mechanism for system call investigation has been suggested in [15]. The solution identifies system call number if a said process is running in some system call. However, the mechanism is again limited to the older way of system call invocation which is based on software interrupt ‘int 0x80’ instruction led CPU-mode switching.

As well, no process state checkpointing work related to investigation of sysenter-based fast system call invocation by a particular user-level process is reported. Furthermore, no work related to dynamic process migration mechanism incorporating investigation of sysenter-based fast system call invocation is seen.

5. MECHANISM The processor series beginning from Pentium II and higher come up with two special assembly instructions SYSENTER and SYSEXIT for quickly switching among kernel mode and user mode [20]. Since these processors are enabled with fast CPU mode switching feature, the Linux starting from its kernel version 2.6 onwards also has feathered a new system call entry method [2].

It was observed that the software interrupt ‘int 0x80’ based legacy way of system call invocation was slower and showed reduction in performance [17]. Hence, kernel versions arriving after the entry of Pentium II and higher processors series came with a newer and efficient system call entry mechanism [11]. The newly introduced system call entry mechanism in modern kernels is based on utilization of the two special CPU instructions SYSENTER and SYSEXIT which are part of the fast system call invocation feature, and they are optimized to offer better performance for CPU mode switching to protection ring 0 and vice versa [1].

Some of the foremost steps for investigating the SYSENTER and SYSEXIT based fast system call invocation mechanism are described here:



Pass on the process identifier (of the desired process whose investigation is to be carried out) from user-space to kernel-space using special ioctl system call function.

In kernel-level, within a kernel module, receive the process id (say pid) sent from the user-space in step 1.

From within the kernel module, determine and fetch reference to the related process descriptor which represents the concerned process context of the pid received in step 2.

If the related process descriptor is not found, the algorithm returns with an appropriate error number -1 to the user-space indicating the error message: “Invalid process or process identifier <pid>”.

From the process context obtained in step 3, determine and fetch the processor register context which is of dynamic nature.

Fetch the value of the system call number from the register orig_ax available in the register context.

From the value of the system call number register obtained in the step 5, determine whether the concerned process is running in some system call or not.

If the concerned register is not found to possess some valid system call number, then the algorithm returns with a suitable return code -2 indicating an appropriate message “The said process is not in system call”.

From the register context, determine the base pointer %ebp which was assigned the value of %esp by concerned system call entry-macro in past at the time of call to the system call in kernel-space. After completion of the system call, the %ebp helps the kernel in restoring the user-space stack.

From the register context, determine the value of thread info flags for the offset %ebp which is determined instep 7.

Determine whether the thread info flags for the offset %ebp register or the %ecx register, possess valid system call reference or not.

If not, then the algorithm returns with a suitable return code -3 indicating an appropriate message “Process<pid> is not in system call”.

Otherwise, stop the algorithm after returning the system call number which is identified in step 6 indicating that the concerned process is running in the respective system call number returned herewith.

The algorithm returns with a respective system call number indicating an appropriate message “Process <pid> is in the system call <system call number> : <system call name>”.

The orig_ax register in above described step 5 is a key member of the kernel data structure pt_regs. However, in some kernel versions, it may be available as orig_eax.

In our implementation, for the above described step 9, the authors obtained a valid system call reference as 1024.

6. EXPERIMENTS The above suggested solution algorithm was implemented in the form of dynamically loadable kernel module on 64-bit Fedora Core 20 system having i5 processor and kernel 3.18.8 compiled with sysenter-based fast system call invocation. The behavior of the above suggested algorithm had been experimented while- (i) the processes were running in

http://www.iaeme.com/IJCET/index.asp

system calls, and (ii) the processes were nscenarios are described below in this section:

The Figure 1the userfigure 1executing in the

The Figure through the usershown in figure 2(a)currently executing in theseconds as per the request made to the

The Figure 3(a) shows a program shows execution of the program shown in figure process is running some infinite loop.

The Figure call. Figure 4(b)gives a hint that the program is running some infinite loop.



The Figure 1(a) the user-level function figure 1(a). The execution shown in the figure 2executing in the read()

The Figure 2(a)through the user-level function shown in figure 2(a)currently executing in theseconds as per the request made to the


The Figure 4(a)call. Figure 4(b) shows the execution of thgives a hint that the program is running some infinite loop.




(a) shows a program scenario having call to the level function scanf()

xecution shown in the figure 2read() system call as the process is waiting for input from keyboard.

2(a) shows a program scenlevel function

shown in figure 2(a). The execution shown in the figure currently executing in the nanosleep()seconds as per the request made to the


4(a) shows a Tower of Hanoi program scenario without hashows the execution of th

gives a hint that the program is running some infinite loop.

(a). User-level program having call to

(b). Execution of user

Figure 1




shows a program scenario having call to the scanf()[9]. Figure

xecution shown in the figure 2system call as the process is waiting for input from keyboard.

hows a program scenlevel function sleep()

. The execution shown in the figure nanosleep()

seconds as per the request made to the nanosleep()The Figure 3(a) shows a program scenario without having any system call. Figure

shows execution of the program shown in figure process is running some infinite loop.

shows a Tower of Hanoi program scenario without hashows the execution of th


level program having call to

Execution of user

Figure 1 Experimentation on


6

system calls, and (ii) the processes were not running in system calls. Such experimental scenarios are described below in this section:

shows a program scenario having call to the . Figure 1(b) shows execution of the program shown in

xecution shown in the figure 2 gives a hint that the process is currently system call as the process is waiting for input from keyboard.

hows a program scenario having sleep()[9]. Figure

. The execution shown in the figure nanosleep() system call as the process is sleeping for 50

nanosleep()

scenario without having any system call. Figure shows execution of the program shown in figure 3(a)

shows a Tower of Hanoi program scenario without hashows the execution of the program shown in figure



Execution of user-level program shown in Fig. 1

Experimentation on read()


ot running in system calls. Such experimental

shows a program scenario having call to the shows execution of the program shown in gives a hint that the process is currently

system call as the process is waiting for input from keyboard.ario having call to the

. Figure 2(b) shows the execution of. The execution shown in the figure 4 gives a hint that the process is

system call as the process is sleeping for 50 nanosleep() system call using parameter.scenario without having any system call. Figure

3(a). The figure

shows a Tower of Hanoi program scenario without hae program shown in figure


level program having call to read()

level program shown in Fig. 1

read() system call


[email protected]


shows a program scenario having call to the read() system call through shows execution of the program shown in gives a hint that the process is currently

system call as the process is waiting for input from keyboard.call to the nanosleep()

shows the execution ofgives a hint that the process is

system call as the process is sleeping for 50 system call using parameter.

scenario without having any system call. Figure . The figure 3(b) gives a hint that the

shows a Tower of Hanoi program scenario without hae program shown in figure 4(a)

system call


system call


[email protected]


system call through shows execution of the program shown in gives a hint that the process is currently

system call as the process is waiting for input from keyboard.nanosleep() system call

shows the execution of the program gives a hint that the process is

system call as the process is sleeping for 50 system call using parameter.

scenario without having any system call. Figure gives a hint that the

shows a Tower of Hanoi program scenario without having any system 4(a). The figure

[email protected]


system call through shows execution of the program shown in gives a hint that the process is currently

system call as the process is waiting for input from keyboard. system call

the program gives a hint that the process is

system call as the process is sleeping for 50

scenario without having any system call. Figure 3(b) gives a hint that the

ving any system . The figure 4(b)

http://www.iaeme.com/IJCET/index.asphttp://www.iaeme.com/IJCET/index.asp

(a)

(a). User



(a). User-level program having call to

(b). Execution of use

Figure 2 Experimentation on

User-level program having infinite loop but not having




Execution of use

Experimentation on

level program having infinite loop but not having


7

level program having call to nanosleep()


Experimentation on nanosleep()



nanosleep()


nanosleep() system call



[email protected]

nanosleep() system call


system call

level program having infinite loop but not having any system call

[email protected]

system call

any system call

[email protected]



Figure 3

(a).

Figure 4



(b). Execution of user

Figure 3 Experimentation on program having infinite loop but no system call

. User-level Tower

(b) Execution of user

Figure 4 Experimentation on Tower



Execution of user

Experimentation on program having infinite loop but no system call

level Tower-of-Hanoi program not having any system call

Execution of user

Experimentation on Tower


8



Hanoi program not having any system call

Execution of user-level program

Experimentation on Tower-of-Hanoi program having no system call






Hanoi program having no system call


[email protected]




shown in Fig. 7



[email protected]




[email protected]


7. RESULTSThis section describes the behavior of the suggested mechanism on various experimental program scenarios de

The Figure 5shown in the figure 1(b)/var/log/messagesin the read()

Figure

Figure the figure /var/log/messagesin the nanosleep()

Figure

Figure 7the figure /var/log/messagesnot running in any system call.

Figure


RESULTS This section describes the behavior of the suggested mechanism on various experimental program scenarios de

The Figure 5 shown in the figure 1(b)/var/log/messages

read() system call.

Figure 5 Application of suggested solution mechanism on

Figure 6 shows application of the suggested solution mechanism on the process shown in the figure 2(b). The figure/var/log/messages

nanosleep()

Figure 6 Application of suggested solution mechanism on

Figure 7 shows application of thethe figure 3(b). /var/log/messagesnot running in any system call.

Figure 7 Application of suggested solution mechanism on t



This section describes the behavior of the suggested mechanism on various experimental program scenarios described in the previous section 6.

shows application of the suggested solution mechanism on theshown in the figure 1(b). The figure /var/log/messages log file, confir

system call.

Application of suggested solution mechanism on

shows application of the suggested solution mechanism on the process shown in . The figure

/var/log/messages log file, confirmnanosleep() system call.


shows application of the The figure

/var/log/messages file, confirms that thenot running in any system call.

Application of suggested solution mechanism on t



This section describes the behavior of the suggested mechanism on various experimental scribed in the previous section 6.

shows application of the suggested solution mechanism on the. The figure

log file, confirms that the process in figure 1(b)


shows application of the suggested solution mechanism on the process shown in . The figure 6, by showing the kernel modules out

log file, confirmsystem call.


shows application of the suggested solution algorithm The figure 7, by showing the kernel modules output from

file, confirms that thenot running in any system call.



9


shows application of the suggested solution mechanism on the. The figure 5, by showing the kernel modules output from

ms that the process in figure 1(b)


shows application of the suggested solution mechanism on the process shown in , by showing the kernel modules out

log file, confirms that the process in figure


suggested solution algorithm , by showing the kernel modules output from

file, confirms that the process shown in the figure




shows application of the suggested solution mechanism on the, by showing the kernel modules output from

ms that the process in figure 1(b)

Application of suggested solution mechanism on the program executing in Fig. 2


s that the process in figure


suggested solution algorithm , by showing the kernel modules output from

process shown in the figure



[email protected]

This section describes the behavior of the suggested mechanism on various experimental

shows application of the suggested solution mechanism on the, by showing the kernel modules output from

ms that the process in figure 1(b) is currently running

the program executing in Fig. 2


s that the process in figure 2(b) is currently running


suggested solution algorithm on the process shown in , by showing the kernel modules output from

process shown in the figure

he program executing in Fig. 6

[email protected]


shows application of the suggested solution mechanism on the , by showing the kernel modules output from

is currently running


shows application of the suggested solution mechanism on the process shown in , by showing the kernel modules output from



on the process shown in , by showing the kernel modules output from

process shown in the figure 3(b) is currently


[email protected]


process , by showing the kernel modules output from



shows application of the suggested solution mechanism on the process shown in put from



on the process shown in , by showing the kernel modules output from

is currently



Figure 8the figure /var/log/messagessystem call.

Figure

From the behavior depicted in the figure mechanism properly detects system calls if the respective processes (figure 2(b)) are running in a system call. On the other side, from the behavior depicted in the figure 7 and figure processes are not running

Hence, it is concluded that the suggbe utilized by the kernel level process control and management mechanisms including process forensic and dynamic

8. CONCLUSIONThe paper describes a novel approach of investigatingthrough this paper helps in determining system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process migration,

REFERENCES[1]

[2]

[3]

[4] [5] [6]

[7]


Figure 8 shows application of the suggested solution mechanism on the process shown in the figure 4(b). The figure/var/log/messagessystem call.

Figure 8 Application of suggested solution mechanism on t

From the behavior depicted in the figure mechanism properly detects system calls if the respective processes (figure

) are running in a system call. On the other side, from the behavior depicted in the figure and figure 8, it is seen that the suggested m

processes are not runningHence, it is concluded that the sugg

be utilized by the kernel level process control and management mechanisms including process forensic and dynamic

ONCLUSIONThe paper describes a novel approach of investigatingthrough sysenterhis paper helps in determining

system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process migration, process investigation

EFERENCES Andries, B. (2005).

http://www.win.tue.nl/

Daniel, Bed. USA: O’

Daniel, Systems.

Dejan, M

Dtrace. (2015).

GDB: The GNU Project Debugger. http://www.gnu.org

Ktrace. (2015). Retrieved May 19, 2015, fromhttp://manpages.ubuntu.com/manpages/lucid/man2/ktrace.2freebsd.html



shows application of the suggested solution mechanism on the process shown in . The figure

/var/log/messages file, confirms that the process is currently not running in any



) are running in a system call. On the other side, from the behavior depicted in the figure , it is seen that the suggested m

processes are not running in any system call.Hence, it is concluded that the sugg

be utilized by the kernel level process control and management mechanisms including process forensic and dynamic

ONCLUSIONS The paper describes a novel approach of investigating

sysenter-based fast technique for entering system call. The technique discussed in his paper helps in determining

system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process

process investigation

EFERENCES Andries, B. (2005). http://www.win.tue.nl/

B. and Marcoed. USA: O’Reilly p. 401

G. and AnthonySystems. Journal of Paralle

M. (2000).Process Migration

Dtrace. (2015). Retrieved May 19, 2015, from

GDB: The GNU Project Debugger. http://www.gnu.org/software/gdb/

(2015). Retrieved May 19, 2015, http://manpages.ubuntu.com/manpages/lucid/man2/ktrace.2freebsd.html



shows application of the suggested solution mechanism on the process shown in . The figure 8, by showing the kernel modules output from

file, confirms that the process is currently not running in any



) are running in a system call. On the other side, from the behavior depicted in the figure , it is seen that the suggested m

in any system call.Hence, it is concluded that the suggested mechanism works properly

be utilized by the kernel level process control and management mechanisms including process forensic and dynamic process migration mechanism.

The paper describes a novel approach of investigatingbased fast technique for entering system call. The technique discussed in

his paper helps in determining whether a desired process is presently executing in some system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process

process investigation and process checkpoint

Sysenter and vsyscall Page.http://www.win.tue.nl/∼aeb/linux/lk/lk

Marco, C. (2005).p. 401-5.

Anthony, C. (2005). Journal of Parallel and Distributed Computing

Process Migration

Retrieved May 19, 2015, from

GDB: The GNU Project Debugger. /software/gdb/



10




From the behavior depicted in the figure 5 and the figure mechanism properly detects system calls if the respective processes (figure

) are running in a system call. On the other side, from the behavior depicted in the figure , it is seen that the suggested mechanism properly detects that the respe

in any system call. ested mechanism works properly

be utilized by the kernel level process control and management mechanisms including process migration mechanism.

The paper describes a novel approach of investigatingbased fast technique for entering system call. The technique discussed in

whether a desired process is presently executing in some system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process

and process checkpoint

Sysenter and vsyscall Page.aeb/linux/lk/lk-4.html#ss4.6

(2005). System Calls. In

(2005). Non-l and Distributed Computing

Process Migration. ACM Journal of

Retrieved May 19, 2015, from

GDB: The GNU Project Debugger. (2015). Retrieved May 19, 2015, from /software/gdb/






and the figure 6mechanism properly detects system calls if the respective processes (figure

) are running in a system call. On the other side, from the behavior depicted in the figure echanism properly detects that the respe

ested mechanism works properly be utilized by the kernel level process control and management mechanisms including

process migration mechanism.

The paper describes a novel approach of investigating system calls which are invokbased fast technique for entering system call. The technique discussed in

whether a desired process is presently executing in some system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundprocess control and management applications such as process forensics, dynamic process

and process checkpoint-restart in distributed systems.

Sysenter and vsyscall Page.(2015). Retrieved May 19, 2015, from4.html#ss4.6

System Calls. In Understanding

-cooperative l and Distributed Computing, 65(9):1022

CM Journal of Computing Surveys

Retrieved May 19, 2015, from http://dtrace.org/blogs/about/

(2015). Retrieved May 19, 2015, from

http://manpages.ubuntu.com/manpages/lucid/man2/ktrace.2freebsd.html


[email protected]




6, it is seen that the suggested mechanism properly detects system calls if the respective processes (figure


ested mechanism works properly and its services can be utilized by the kernel level process control and management mechanisms including

system calls which are invokbased fast technique for entering system call. The technique discussed in

whether a desired process is presently executing in some system call. The mechanism is applicable to the Intel’s Pentium II and onfamily. The suggested approach is one of the noteworthy foundations for various kernelprocess control and management applications such as process forensics, dynamic process

start in distributed systems.


Understanding the Linux Kernel. 3rd

Load Balancing in Distributed 65(9):1022-34.

Computing Surveys

http://dtrace.org/blogs/about/




[email protected]




n that the suggested mechanism properly detects system calls if the respective processes (figure 1(b) and figure


and its services can be utilized by the kernel level process control and management mechanisms including

system calls which are invokbased fast technique for entering system call. The technique discussed in

whether a desired process is presently executing in some system call. The mechanism is applicable to the Intel’s Pentium II and onwards processors

ations for various kernelprocess control and management applications such as process forensics, dynamic process



the Linux Kernel. 3rd

Load Balancing in Distributed 34.

Computing Surveys, 32(3):241

http://dtrace.org/blogs/about/



[email protected]




n that the suggested and figure

) are running in a system call. On the other side, from the behavior depicted in the figure echanism properly detects that the respective

and its services can be utilized by the kernel level process control and management mechanisms including

system calls which are invoked based fast technique for entering system call. The technique discussed in

whether a desired process is presently executing in some wards processors

ations for various kernel-level process control and management applications such as process forensics, dynamic process



the Linux Kernel. 3rd

Load Balancing in Distributed

32(3):241-99.




[8] LINUX Kernel Source. (2015). Retrieved May 19, 2015, from http://kernel.org

[9] LINUX Reference Manual- section 2 and 3. (2015). Retrieved May 19, 2015, Available In Linux System.

[10] Ltrace. (2015). Retrieved May 19, 2015, from http://man7.org/linux/man-pages/man1/ltrace.1.html

[11] Manu, G., Sysenter Based System Call Mechanism in Linux. (2015). Retrieved May 19, 2015, from http://articles.manugarg.com/systemcallinlinux2_6.html

[12] Narayan, J., and Darshan, C. (2009).Process Forensic for System-call details on Linux Platform. International Journal of Computer Applications in Engineering, Technology and Sciences, 2(1):510-2.

[13] Narayan, J., and Darshan, C. (2012).Mechanism for Implementation of Load Balancing using Process Migration. International Journal of Computer Applications, 40(9):16-8.

[14] Narayan, J., (2014). Load Balancing in Cloud Using Process Migration. International Journal of Advanced Research in Engineering and Technology, 5(4):230-8.

[15] Narayan, J., and Darshan, C. (2014).Implementation of Process Forensic for System Calls. International Journal of Advanced Research in Engineering and Technology, 5(6):77-82.

[16] Ptrace. (2015). Retrieved May 19, 2015, from http://linux.die.net/man/2/ptrace

[17] Robert L. (2013). System Calls. In Linux Kernel Development (pp. 73). USA: Pearson.

[18] Sancho, J., Petrini, F., Davis, K., Gioiosa, R., and Jiang, S. (2005, April). Current Practices and a Direction Forward in Checkpoint/Restart Implementation for Fault Tolerance. Paper presented at 19thIEEE International Symposium on Parallel and Distributed Processing. Strace. (2015). Retrieved May 19, 2015, from https://wiki.ubuntu.com/Strace

[19] Wolfgang, M., (2008).System Calls. In Professional Linux Kernel Architecture (pp. 833). USA: Wiley

[20] Yi-Min, W., Yennun, H., Kien-Phong, V., Pe-Yu, C., and Kintala, C. (1995, June). Checkpointing and its Applications. Paper presented at 25th International Symposium on Fault-tolerant computing.

[21] Nana Kwame Gyamfi, Makafui Nyamadi, Prince Appiah, Dr. Ferdinand Katsriku and Dr. Jama-Deen Abdulai, A Brief Survey of Mobile Forensics Analysis on Social Networking Application. International Journal of Computer Engineering and Technology, 7(4), 2016, pp. 81–86.

[22] Showkat Ahmad Dar, S. A. and Lone, S. A. An Application of Morphological Image Processing to Forensics. International Journal of Computer Engineering and Technology, 6 (8), 2015, pp. 31-40

[23] Dr B. R.Doraswamy Naick and Neelima Bachalla, Application of Digital Forensics in Digital Libraries. International Journal of Library & Information Science, 5 (2), 2016, pp.89–94.

International Journal of Computer Engineering & Technology ... · International Journal of Computer Engineering & Technology (IJCET) Volume 8, Issue 4 , July -August 2017 , pp. 1

Documents