Anatomy of a simple Linux utility
How Does the Shell Execute ls?
Once the file corresponding to the typed command is found, a call to the execve()
system call is made from the function shell_execve()
in the file execute_cmd.c
. The call is defined in the kernel (fs/exec.c
) as shown in Listing 9.
Listing 9
Kernel Definition of execve()
Effectively, the do_execve()
function does the work. do_execve()
has the following prototype:
int do_execve (struct filename *filename, const char __user *const __user *__argv, const char __user *const __user *__envp)
Using the SystemTap script shown in Listing 10, I place a probe at the do_execve()
function; struct filename
is defined in include/linux/fs.h
as follows:
struct filename { const char *name; /* pointer to actual string */ const __user char *uptr; /* original userland pointer */ struct audit_names *aname; bool separate; /* should "name" be freed? */ };
Listing 10
Tracing Calls to and from do_execve()
Hence, I use $file->name
to retrieve the filename of the binary that is being executed.
Invoking this SystemTap script with the following
stap -v do_execve.stap
and executing ls
in another terminal window produces:
The process ID of the executing ls
process is 26013, and the binary corresponding to the command that is executed is /bin/ls
. Several other things have to happen before the binary /bin/ls
is executed. For example, the program has to be read from the disk, its binary format needs to be found, and the appropriate handling code must read the binary into memory.
The SystemTap script in Listing 11 probes some of the key functions that show how the /bin/ls
binary is loaded into memory. If you run the SystemTap script and execute the ls
command in another window, you will see output similar to Listing 12 in the SystemTap window.
Listing 12
Is Executable Format Supported?
Listing 11
SystemTap Trace
The search_binary_handler()
function iterates through the list of currently supported binary formats and, once it finds that the executable is a supported format, proceeds to call the appropriate function to load the binary. In this case, it is the function load_elf_binary()
.
Dynamic and Static Linking
You can see that the glibc loader (/lib64/ld-linux-x86-64.so.2
) is opened, because ls
dynamically loads glibc
into memory.
To see how things are different when you compile a program statically, compile the C program in Listing 13 with
gcc -o simple simple.c
Listing 13
The printf() Library Function Call
and execute it while keeping the SystemTap script in Listing 11 running (see Listing 14).
Listing 14
SystemTap Output with Simple Program
Next, compile the program, passing the -static
flag to gcc
as
gcc -o simple_static simple.c -static
and execute the program. On Fedora 21, you need to have the glibc-static
package. You should see the output shown in Listing 15 in the SystemTap window.
Listing 15
Statically Compiled Program
In this case, you can see that the loader is not being opened any more. Now, a number of things have to happen before the program is executed, including setting up the memory areas and copying over the arguments, as well as a handful of other tasks.
Retrieving the Files List from Disk
At this stage, the program is in memory and ready to execute when it gets a chance. So, how does ls
read the directories and files from disk, and what happens in the kernel space to make that happen?
The ls
utility uses the readdir(3)
function to read the directory contents, which in turn invokes the getdents()
system call defined as follows in fs/readdir.c
:
SYSCALL_DEFINE3\ (getdents, unsigned int, fd, struct linux_dirent __user*, \ dirent, unsigned int,count)
The getdents()
system call invokes the iterate_dir()
function, also defined in the same file. This function reads the list of files in the directory by consulting the underlying filesystem's inode entries. Depending on which filesystem the path specified to ls
is formatted, the function used to read the directory contents will vary. On ext4, the ext4_readdir()
function in fs/ext4/dir.c
is the function that does this, and the filldir()
function in fs/readdir.c
is called for every entry it finds.
The SystemTap script in Listing 16 traces the retrieval of the directory listing. The filldir()
function prototype is:
static int filldir(void * __buf, const char * name, int namlen, \ loff_t offset, u64 ino, unsigned int d_type)
Listing 16
Tracing Locations
The argument name
corresponds to the file name of a file in the directory in which ls
is invoked; hence, I print it in the SystemTap script. If you run the above SystemTap script and execute ls
in another terminal window, you should see output similar to Listing 17 in the SystemTap window.
Listing 17
Output of ls on ext4 Filesystem
In Listing 17, you can see that besides the lines showing filldir
, each of the filenames in the directory in which ls
is executed is shown, including hidden files. Once the entries have been retrieved, the getdents()
system call returns and the list of files appears in your terminal window.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs