Beyond the Veil: Exploring System Calls

[Chetan_Tiwary_]

Have you ever wondered what happens behind the scenes when you run : " ls newdir/ " in your terminal ?

Every action, from opening a file to launching an application, involves a series of system calls. In this post, we'll explore the powerful strace tool and delve into the world of system calls, revealing the intricate workings of your Linux system.

The strace utility displays information about system calls made by a process. This command helps identify the kernel function on which a program spends its time.

A system call is essentially a request from a program to the operating system's kernel for a specific service. Lets run our command and there will be lot of actions behind the veil until we get the result :

[root@servera]#ls newdir

*************background actions********* following with strace command**************

Lets break down the calls one by one : 

• execve("/bin/ls", ["ls", "newdir/"]          when you execute a program, a running process needs to call fork() to create a new process by duplicating itself. This duplicated process, a "child" process, then calls execve() (which is the first syscall you see listed by strace) : it replaces the current process with the /bin/ls executable.
• brk(NULL) :  the process asking where its heap memory ends.
• access("/etc/ld.so.preload", R_OK): Checks if the process has read access to the /etc/ld.so.preload file ( which is used to load shared libraries ).
• openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC)                                                 Opens the /etc/ld.so.cache file for reading in read-only mode and closes it when the process exits.
•  fstat(3, {st_mode=S_IFREG|0644, st_size=27749,......    Gets information about the file descriptor 3 (which refers to /etc/ld.so.cache).
•  mmap(NULL, 27749, PROT_READ, MAP_PRIVATE, 3, 0)   Maps the contents of the file descriptor 3 (i.e., /etc/ld.so.cache) into memory.
•  close(3)                 Closes the file descriptor 3.

set_robust_list(0x7f38af670920, 24)     Sets the robust list for the process, which is used for recovery in case of a crash.

rt_sigaction(SIGRTMIN, {sa_handler= …………}       Sets the signal handler for the real-time signal SIGRTMIN.

prlimit64(0, RLIMIT_STACK, NULL, …………….)        Sets the stack size limit for the process.

statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID ST_RELATIME})  

• Gets information about the /sys/fs/selinux filesystem.

statfs("/sys/fs/selinux") system call is essential for understanding and managing SELinux security policies and configurations

ioctl(1, TCGETS……….)       gets terminal attributes for the standard input

ioctl(1, TIOCGWINSZ, {ws row=30……..)     Gets the window size for the standard input

getdents64(3, / 0 entries /, 32768)    Reads directory entries from the file descriptor 3

write(1, "fileA fileB\n", 13)        Writes the string "fileA fileB\n" to the standard output

and then we see this final result in the screen : 

The next time you casually type ls, remember the intricate symphony of system calls that make it happen. You're welcome!!

[Chetan_Tiwary_]

So, just to summarise and categorise the various system calls :

• Process Management:

  • fork(): Creates a new process (child process) as a copy of the parent process.
  • exec(): Replaces the current process with a new program.
  • wait(): Waits for a child process to terminate.
  • exit(): Terminates the current process.

• File Management:

  • open(): Opens a file and returns a file descriptor.
  • read(): Reads data from an open file.
  • write(): Writes data to an open file.
  • close(): Closes a file.
  • mkdir(): Creates a directory.
  • rmdir(): Removes a directory.

• Device Management:

  • read() (for devices): Reads data from an input device.
  • write() (for devices): Writes data to an output device.
  • ioctl(): Controls device attributes and operations.
  • select(): Waits for I/O operations on multiple devices.

• Network Management:

  • socket(): Creates a socket for network communication.
  • connect(): Establishes a connection to a network endpoint.
  • send(): Sends data over a network connection.
  • recv(): Receives data over a network connection.

• System Information:

  • getpid(): Gets the process ID of the current process.
  • getuid(): Gets the user ID of the current process.
  • gethostname(): Gets the hostname of the system.
  • sysinfo(): Gets system information such as memory usage and process count.

[Trevor]

System Calls

Now this is a concept that definitely involves looking under the hood!  As usual, another
marvelous presentation of a topic that truly can require some heavy mental lifting, was
delivered by Chetan!

While I'm here, I'll just add a couple of stickers to the already handsomely
decorated box:

-  System calls are a way for programs to ask for a service from the kernel.

-  System calls are how a program enters the kernel to perform some task.

-  System calls are usually made when a process in user mode requires access to
a resource. Then, that process requests the kernel to provide the resource via a
system call.

-  A system call changes the processor state from user mode to kernel mode, so that
the CPU can access protected kernel memory.

-  The kernel is the part of the Linux operating system that has control over everything.

-  The kernel  provides access to hardware by using kernel modules (drivers).

-  The kernel provides basic services to all other parts of the operating system.

If you extract nothing else from your understanding of system calls, the recurring
reference to the kernel suggest there's a connection between the two.  However, I'm
sure you gathered much more, with Chetan's presentation providing a lot of food for
thought and consumption!!!

[Chetan_Tiwary_]

@Trevor Thanks for your insightful addition to the post.

You have touched a very important part  :

"System calls are usually made when a process in user mode requires access to
a resource. Then, that process requests the kernel to provide the resource via a
system call.

-  A system call changes the processor state from user mode to kernel mode, so that
the CPU can access protected kernel memory."

First of all why we need user mode and kernel mode ? simple: Doctrine of separation ( LOL ) .

To protect the integrity of programs and their data, the CPU must have at least these two privilege levels. Kernel mode programs have full control over memory, peripherals, and program switching, while user mode programs have limited access to resources and can be interrupted at any time.

To maintain system security, user-mode programs should not have the ability to directly transition back to kernel mode. However, they often need to interact with hardware devices or perform privileged operations that require kernel-level access.

The system call is a mechanism that allows a user-mode program to request services from the kernel without directly entering kernel mode. The program provides arguments to the system call, indicating the specific service it needs.

When the program executes a trap instruction, the CPU switches to kernel mode and jumps to a predefined location in memory. This location contains the system call handler, which is part of the operating system and is protected from modification by user-mode programs.

The system call handler processes the request, performs the necessary actions in kernel mode, and then returns control to the user-mode program. This ensures that the kernel maintains control over privileged operations and prevents unauthorized access.

The mode bit is a flag in the CPU that indicates whether the system is currently in user mode or kernel mode. When a user process requests a system call, the CPU switches from user mode ( bit mode 1 )  to kernel mode ( bit mode 0 ). This allows the kernel to handle the system call and perform privileged operations. Once the system call is complete, the CPU switches back to user mode, returning control to the original process.

[Wasim_Raja]

Great breakdown of the system calls that occur behind a simple command like ls. I appreciate how strace helps visualize these hidden operations from process management to file handling. Your detailed analysis of system calls like execve, brk, and write illustrates how deeply intertwined they are with everyday tasks.

Thanks for this insightful guide