The functions of the OS is to manage system resources. What are system resources? These are the hardware components of the computer that support the execution of a programmer or organization of information. Typically, we describe the set of system resources coordinated by the OS as:

• Device Management : Hardware devices, such as keyboard, monitors, printers, hard drives, etc., are resources managed by the computer. When a programmer wishes to interact with these devices, a unified interface provided by the OS is used.
• Process Management : The invocation and execution of a program, a process, is managed by the OS, including managing its current state, running or stopped, as well as the loading of code.
• Memory Management : The access to physical and virtual memory is controlled by the OS, and a programs memory layout and current allocations is carefully managed.
• File System Management : The OS is also responsible for ensuring that programs can read and write from the filesystem, but also that programs don't corrupt the file sysystem or access files/directory that they do not have permission to.

So far in this class, we've written programs (either in Bash or C) that have required access to those resources. For example, we've read user-input through keyboard (device management); we've invoked and executed programs through bash (process management); we've allocated and deallocated memory in C using malloc() and calloc() (memory management); and, we've read, written, and created files in both C and Bash (file system management).

In each of those cases, while it is nice to think that we, as the programmer, have done these things, in fact, the operating system has performed these actions on our behalf in a supervisory role. This is mostly for our protection and convenience. Would you really want to have to read directly from the keyboard driver in order to get input from the user? Would you want to write to the display driver to print information back? Maybe you do, if you're nuts about computing, but most of us don't. And further, if you do want to perform these low level actions yourself, it's really easy to mess it up, at which point, your computer may be broken forever. For example, if you had to manipulate the filesystem directly, and you made a mistake —oops, you just lost all your files!

The kernel of the OS is a program that is trusted to perform all the protected system resource actions. The kernel is trusted software and executes in supervisory mode, and all the basic OS functionality is implemented from with the kernel software. We describe the domain of the kernel as kernel-space. Actions that can be performed without privilege, that is, do not require the kernel, are described as part of the user domain, or user-space.

The distinction between these two domains is important. For example, adding two numbers together, a process completed by an add instruction on the processor, is unprivileged and is performed in user-space. Similarly, the action of iterating through an array and reading and writing data already allocated in memory is also unprivileged and performed in user-space. But, the allocation of new memory, by adjusting the break point, for example, is a privileged process, and must be completed by the kernel.

The invocation of the kernel to perform a context switch occurs through a trap. A trap is a special instruction to the processor that an operation is needed from the kernel. The processor interrupts the current execution of the program, saves the state, and invokes the kernel with the trap information. In the running example, this will be a trap for the kernel function sys_sbrk() which was invoked via the system call sbrk().

The kernel will then fulfill the request via the kernel function. Once that function returns, the kernel is context switched out, the user process is context switched in, and execution continues as before.

So far in this class we haven't been using the system call interface directly, but rather we have used the C standard library to interface for us. This is going to change as we explore the Unix system, and it is important that you can identify the differences between library functions and system calls.

The easiest way to do this is via the manuals. The man pages are divided into sections to better organize the plethora of manuals available. There is a total of 8 sections, and below are the relevant ones.

• Section 1: General commands, such as those found in the bash environment
• Section 2: System calls, such as sbrk()
• Section 3: Library functions, such as malloc()
• Section 8: System Administration, … get to that later

For example, if we type, man malloc, and inspect the header of the manual, we can learn a lot of information:

MALLOC(3)           Linux Programmer's Manual                    MALLOC(3)

NAME
       malloc, free, calloc, realloc - Allocate and free dynamic memory

SYNOPSIS
       #include <stdlib.h>

       void *malloc(size_t size);
       void free(void *ptr);

First we can see that malloc() is in section 3 of the manual via MALLOC(3) header. Also, from the synopsis, we see that it is a part of the C standard library via the #include <stdlib.h>. As a comparison, let's look at the manual for sbrk().

BRK(2)              Linux Programmer's Manual                        BRK(2)

NAME
       brk, sbrk - change data segment size

SYNOPSIS
       #include <unistd.h>

       int brk(void *addr);

       void *sbrk(intptr_t increment);

The sbrk() command, with brk(), is in section 2 of the manual via the BRK(2) header, and it also in the unix standard library, which we know from #include <unistd.h>.

One problem you may encounter is that there are manuals that have the same name. For example, there is the read command for bash, which is a general command in section 1 of the manual, and there is also the system call read(), which is in section 2 of the manual. The preference for the man command is to always retrieve lower numbered manuals. For example,

man 2 read

will display the bash read command and not the system call read(). To access the system call manual for read(), use

#> man 2 read
READ(2)                  Linux Programmer's Manual                     READ(2)

NAME
       read - read from a file descriptor

SYNOPSIS
       #include <unistd.h>

       ssize_t read(int fd, void *buf, size_t count);

To begin, let's look at a simple program that prints "Hello World"

int main(){
   char hello[]= "Hello World!";
   puts(hello);
}

This program is not very complicated. It defines a string called hello that references the string "Hello World." The string is then outputted using puts() which puts the string to standard out, like printf(), but since we are not doing any formatting, we use the simpler output method.

We can compile and execute the program like before:

user@ic221-unix$ gcc helloworld.c -o helloworld   
user@ic221-unix$ ./helloworld 
Hello, World!

What we would like to do now is trace this program to see what library calls are used during execution. We can do this with ltrace, and we redirect the output so it doesn't interfere with the output of the ltrace

user@ic221-unix$ ltrace ./helloworld > /dev/null 
__libc_start_main(0x400596, 1, 0x7ffea979c798, 0x4005f0 <unfinished ...>
puts("Hello, World!")                                  = 14
+++ exited (status 0) +++

And we can clearly see that, yes, indeed this program calls puts(). This is a library function. We could also look at malloc like our previous examples and see the library functions, like in the program below:

typedef struct{
  int a;
  int b;
} pair_t;

int main(){

  pair_t * pair = malloc(sizeof(pair_t));
  pair->a=10;
  pair->b=20;

  printf("(%d,%d)\n", pair->a,pair->b);
}

Here's the output normally and with ltrace:

user@ic221-unix$ ./pair 
(10,20)
user@ic221-unix$ ltrace ./pair > /dev/null 
__libc_start_main(0x400566, 1, 0x7ffcea276338, 0x4005c0 <unfinished ...>
malloc(8)                                              = 0x2411010
printf("(%d,%d)\n", 10, 20)                            = 8
+++ exited (status 0) +++
user@ic221-unix$

This time there are two library methods called, and these are ones that match the program. But there is actually more going on.

If were to add the -S flag to ltrace we get a bit different narrative of our program. The -n flag says to indent nested function calls so we can more clearly see the process of the program.

user@ic221-unix$ ltrace -S -n 3 ./helloworld > /dev/null 
SYS_brk(0)                                             = 0x11e8000
SYS_access("/etc/ld.so.nohwcap", 00)                   = -2
SYS_mmap(0, 8192, 3, 34)                               = 0x7f3877a78000
SYS_access("/etc/ld.so.preload", 04)                   = -2
SYS_open("/etc/ld.so.cache", 524288, 01)               = 3
SYS_fstat(3, 0x7ffd9b688060)                           = 0
SYS_mmap(0, 0x614c, 1, 2)                              = 0x7f3877a71000
SYS_close(3)                                           = 0
SYS_access("/etc/ld.so.nohwcap", 00)                   = -2
SYS_open("/lib/x86_64-linux-gnu/libc.so.6", 524288, 016751740550) = 3
SYS_read(3, "\177ELF\002\001\001\003", 832)            = 832
SYS_fstat(3, 0x7ffd9b6880b0)                           = 0
SYS_mmap(0, 0x3c8a00, 5, 2050)                         = 0x7f387748c000
SYS_mprotect(0x7f387764c000, 2093056, 0)               = 0
SYS_mmap(0x7f387784b000, 0x6000, 3, 2066)              = 0x7f387784b000
SYS_mmap(0x7f3877851000, 0x3a00, 3, 50)                = 0x7f3877851000
SYS_close(3)                                           = 0
SYS_mmap(0, 4096, 3, 34)                               = 0x7f3877a70000
SYS_mmap(0, 4096, 3, 34)                               = 0x7f3877a6f000
SYS_mmap(0, 4096, 3, 34)                               = 0x7f3877a6e000
SYS_arch_prctl(4098, 0x7f3877a6f700, 3, 34)            = 0
SYS_mprotect(0x7f387784b000, 16384, 1)                 = 0
SYS_mprotect(0x600000, 4096, 1)                        = 0
SYS_mprotect(0x7f3877a7a000, 4096, 1)                  = 0
SYS_munmap(0x7f3877a71000, 24908)                      = 0
__libc_start_main(0x400596, 1, 0x7ffd9b688a48, 0x4005f0 <unfinished ...>
   puts("Hello, World!" <unfinished ...>
      SYS_fstat(1, 0x7ffd9b6887f0)                     = 0
      SYS_ioctl(1, 0x5401, 0x7ffd9b688760, 404)        = -25
      SYS_brk(0)                                       = 0x11e8000
      SYS_brk(0x120a000)                               = 0x120a000
   <... puts resumed> )                                = 14
   SYS_write(1, "Hello, World!\n", 14)                 = 14
   SYS_exit_group(0 <no return ...>
+++ exited (status 0) +++

Notice that this time there is a lot, lot more going on. In particular, there is a number of calls that occur before the main part of our program even gets started at the call to __libc_start_main().

The second thing to notice is everything under main(), which we can duplicate below:

   __libc_start_main(0x400596, 1, 0x7ffd9b688a48, 0x4005f0 <unfinished ...>
   puts("Hello, World!" <unfinished ...>
      SYS_fstat(1, 0x7ffd9b6887f0)                     = 0
      SYS_ioctl(1, 0x5401, 0x7ffd9b688760, 404)        = -25
      SYS_brk(0)                                       = 0x11e8000
      SYS_brk(0x120a000)                               = 0x120a000
   <... puts resumed> )                                = 14
   SYS_write(1, "Hello, World!\n", 14)                 = 14
   SYS_exit_group(0 <no return ...>
+++ exited (status 0) +++

Shows what really happens after we call puts(). There is a bunch of SYS_* calls. What are these? This is a library function in C to make a system call. We can actually call it directly ourselves to make a system call.

C provides a direct way to make a system call in C without going through other library methods: syscall(). The syscall() interface is the following:

           .--- System Call Number
           v
syscall(long number, ...)
                      ^
                      '---- Remaining Arguments to the system call

The first argument, the system call number, is a way to specify which system call you want to call. Each system call has a unique number assigned to it and it is machine code and operating system dependent. For example, in x86 (32-bit), write is system call number 4, but in x86₆₄ (64-bit) write is system call number 1.

As we are working on 64-but machines in the lab, let's rewrite our program to use syscall() to write hello world.

#include <unistd.h>

int main(){
  char hello[] = "Hello, World!\n";

  //      .-- System call number for write()
  //      v
  syscall(1, 1, hello, 14);
  //         \__________/
  //              |
  //              '-- arguments to write() system call
  //                      1: for stdout
  //                  hello: string to write
  //                     14: the length of the string to write
}

Note that the arguments following the system call number match the arguments to the write() system call, which we learned from doing the ltrace above. Now we can run this program to see the output and do another trace of it (focusing only on the output for main()):

user@ic221-unix$ ./syscall 
Hello, World!
user@ic221-unix$ ltrace -S -n 3 ./syscall > /dev/null 
(...)
__libc_start_main(0x400596, 1, 0x7ffd2a7fce18, 0x400610 <unfinished ...>
   syscall(1, 1, 0x7ffd2a7fcd10, 14 <unfinished ...>
      SYS_write(1, "Hello, World!\n", 14)              = 14
   <... syscall resumed> )                             = 14
   SYS_exit_group(0 <no return ...>
+++ exited (status 0) +++

Perfect, we get the same otuput, but we are still seeing that we are actually calling SYS_write() via a library interface. We are still not really calling the system call directly.

The only way to directly invoke a system call is by writing our program not in C, but rather in the programming language that C is compiled into, binary. The language of binary programs on most 64-bit unix machines is x86₆₄. We will use asm style syntax to write a hello world program, and let's see what a hello world program would look like:

SECTION .data
	;;char hello[] = "Hello, World!\n"
        hello	 db "Hello, World!",0x0a 

SECTION .text
	global _start
	
_start:
	;;syscall(1,1,hello,14) 
	mov rax,1
	mov rdi,1
	mov rsi,hello	
	mov rdx,14
 	syscall

	;;syscall(60,0); //exit with status 0
	mov rax,60
	mov rdi,0
	syscall

The mov commands are assignment, and putting values in registers that match the arguments to syscall. We also added an extra system call to exit the program cleaning. Compiling and running this program looks a bit different, but the result is the same.

user@ic221-unix$ nasm -f elf64 helloworld.asm
user@ic221-unix$ ld helloworld.o -o helloworld
user@ic221-unix$ ./helloworld 
Hello, World!

What is interesting now, is that if you were to ltrace this program, you get nothing!

user@ic221-unix$ ltrace -S -n 3 ./helloworld > /dev/null 
Couldn't find .dynsym or .dynstr in "/proc/292/exe"

That's because we are no longer using the C library at all, we are now using the system call interface in its purest form. To see what is happening, we need to use strace, the system call tracing

user@ic221-unix$ strace ./helloworld > /dev/null 
execve("./helloworld", ["./helloworld"], [/* 16 vars */]) = 0
write(1, "Hello, World!\n", 14)         = 14
exit(0)                                 = ?
+++ exited with 0 +++

When you do that, you see that, yes, in fact we are still doing a write(). We are also seeing the execve() system call, which is the system call that starts the execution. This in a sense, is a simple as it gets and as close to the operating system we will go.

In the last lesson, we identified the system resources that the OS is responsible for managing. These include:

• Device Management : Hardware devices, such as keyboard, monitors, printers, hard drives, etc., are resources managed by the computer. When a programmer wishes to interact with these devices, a unified interface provided by the OS is used.
• Process Management : The invocation and execution of a program, a process, is managed by the OS, including managing its current state, running or stopped, as well as the loading of code.
• Memory Management : The access to physical and virotual memory is controlled by the OS, and a programs memory layout and current allocations is carefully managed.
• File System Management : The OS is also responsible for ensuring that programs can read and write from the filesystem, but also that programs don't corrupt the file sysystem or access files/directory that they do not have permission to.

The major theme of this course is understanding the OS System Call API that the Unix system uses to access these resources. So far, we've been using the system call API via the C standard library, but underneath the covers, system calls were being used. As an example of the difference between a system call and a library lesson, in the last lesson, we identified that the memory management functions , malloc() and calloc(), is actually a standard library function. Real memory allocation occurs via the system call sbrk(), which adjust the break point to increase the size of the heap.

In today's lesson, we are going to do the same for the Device Management and File System Management resources. In previous lessons, we have interacted with the file system and performed I/O via the file stream interface, FILE *, and used standard I/O library functions like, fprintf() and fputc() and etc. The file stream interface is a lot like malloc(), it is a nice library feature that provides a service; under the file stream interface lies the system calls that help manage file opening and closing as well as reading and writing from files. We are going to go back to first principles, let's do Hello World again!

From now on, let's assume that we don't have the C standard library, or the C standard I/O library: How do we write our Hello World program? We need to use a lower level function, a system call, to write directly to the standard out device, i.e., the terminal window. The system call that writes to a file or device is write(). Bellow, is a the system call hello world:

#include <unistd.h>

int main(int argc, char * argv[]){
  char hello[] = "Hello World\n";
  char *p;

  for(p = hello ; *p ; p++){
     write(1, p, 1); 
  }

}

Much of this program should be familiar to you. We assign the "Hello World" string to the array hello, and we then iterate over that array one character at a time using pointer arithmetic until the end. The output is via the write() system call, but the specifics of that system call, as well as the complimentary system call, read(), need further explanation.

Both the read() and write() system calls operate over file descriptors rather than file streams, and read from or write to buffers not strings. A file descriptor is just an integer, a number, that refers to a currently open file. The OS uses the file descriptor number as an index into the file descriptor table of currently open files to gain access to the actual device the I/O operations should be performed, like a file on disk, or writing to the terminal, or reading data from the network controller. (We discuss file descriptors more in the next section.)

While you might not know how to open new files yet as a file descriptor, we still have the standard input/output/error streams to work with. Finally, we can use standard descriptor numbers:

• Standard Input : 0 : STDIN_FILENO
• Standard Output : 1 : STDOUT_FILENO
• Standard Error : 2 : STDERR_FILENO

You should note that the file descriptor numbers are the same as the numbers we used for bash programming and redirects … everything is connected. Also, unistd.h provides three constants to refer to the standard file descriptors, STIDN_FILENO, STDOUT_FILENO, and STDERR_FILENO, which can help improve the readbility of your code.

We can now start to piece together the write() command from above a bit more:

//    .-- Write to standard out, file descriptor 1
//    v
write(1, p, 1); 
//       ^  ^
//       |  '--- Number of bytes to write, just the char p points to
//       |
//       '-------- char *, points to the byte we want to write

The first argument to write() is the file descriptor of where we are writing. In this case, we are programming "Hello World", so we want to print to standard out, or file descriptor 1. The next argument is a bit more obvious, p points to a char we want to write, and the last argument is the number of bytes we want to write. Go through the "Hello World" program from top to bottom, we can now see that it just prints each character of the hello string to standard out, one at a time, until the NULL terminator is reached.

Now that we know how to write a string to the terminal using the system call write() without library functions, it's fun to tilt your head a bit and think for a minute about how just this little bit of code, just the write() system call, can be used to program all the file output we've learned so far. How might we program fputc() or printf()? I'm sure you could, but thankfully, we don't have to because someone did it for us in the standard library.

The system call to open a file is open(), which is well named, and the system call to close a file is close(), also well named. These system calls are low level and do operate over file streams, as FILE *, but instead return an integer value which is the file descriptor.

All open files in the operating system are managed via file descriptors, which are indexes into the file descriptor table. The file descriptor table is a kernel data structure which tracks open files for all programs, and we'll discuss the details of this in a later lesson. For the purposes of today, the key concept is that we reference open files via an integer value, the file descriptor.

As previously discussed, each program comes ready made with three open file descriptors, the standard file descriptors. Each has an assigned number: 0, stdin; 1, stdout; and, 2 stderr. When you open a file, it will be assigned the next lowest file descriptor number available, which might be 3 for the first file, and then 4, and so on.

To open a file we use the open() system call is define in the file control librar, fcntl.h, and the function prototype is as follows:

int   open(const char *path, int oflag, ... /*mode_t mode*/ );

There is either two or three arguments to open(). In the simple case, where we are not creating a file, open() only takes two arguments, but if a file is created, we need to specify the permission mode of that file, such ad read/write/exec.

Conceptually, open(), is a lot like fopen() in the simple case when you are opening a file for reading.

int fd = open("path/to/file", O_RDONLY);

The oflag argument is a lot like the mode from fopen(), but instead of using a string we use integer (and binary-combinations thereof) to indicate the desired open condition. Fortunately, these values are defined constants for us, so we don't have to combine integer flags ourselves. In the above example, the file at the given path is opened for reading, only, with O_RDONLY flag.

If we wanted to open a file for writing, truncate the file if it exists or create it if it does not exist, then we need to combine some flags and specify a mode. Here is an example:

int fd = open("test.txt", O_WRONLY | O_TRUNC | O_CREAT, 0664);

The second argument O_WRONLY | O_TRUNC | O_CREAT is often called an ORing, and refers to a set of options that are combined using the bit-wise OR operator. The way this works is that each option sets a bit in a field, in this case, one bit in the integer. The bitwise or, will result in the accumulation of all the set bits.

00000000000000000000000000000001      O_WRONLY
00000000000000000000010000000000      O_TRUNC
00000000000000000000001000000000      O_CREAT
--------------------------------- OR
00000000000000000000011000000001      O_WRONLY | O_TRUNC | O_CREAT

Here are the relevant option flags for opening a file:

• O_RDONLY open for reading only
• O_WRONLY open for writing only
• O_RDWR open for reading and writing
• O_APPEND append on each write
• O_CREAT create file if it does not exist
• O_TRUNC truncate size to 0

The mode portion of the arguments, 0664, is an octet, just like we use for chmod in has. The leading 0 is indicator that the following values are in octal, not base 10.

There are also settings shortcuts to reference different mode settings to use in an ORING

• S_IRUSR 00400 owner has read permission
• S_IWUSR 00200 owner has write permission
• S_IXUSR 00100 owner has execute permission
• S_IRGRP 00040 group has read permission
• S_IWGRP 00020 group has write permission
• S_IXGRP 00010 group has execute permission
• S_IROTH 00004 others have read permission
• S_IWOTH 00002 others have write permission
• S_IXOTH 00001 others have execute permission

So 0644 is equivalent to the ORING:

S_IRUSR | S_IWUSER | S_IRGRP | S_IWGRP | S_IROTH

We since writing modes in octal is relatively straight forward (and less typing), we will switch between these two settings during the semester.

The last aspect of opening and creating files is the user mask, or umask. This is a mechanism to specify which permissions of newly created files should be turned off by default, and functions as a security parameter for the system.

The umask is specified as a mode in octal, just like above, except it is inverted. The bits that are set to one indicate that those permissions should be turned off by default. We can see the current umask of the system using the shell command:

aviv@saddleback: part2 $ umask
0027

The umask of 0027 specifies that files that are initially created should have all other read, write, and execute off and group execute off, but all other permissions should be allowable.

The way this is enforced, is when open() creates a new file it sets the permissions to:

mode & ~umask

The & and ~ symbols are bitwise operators for AND (&) and NOT (). The NOT operator () on bits will invert all the bits, so ones becomes zeros and zeros ones. And the AND operator (&) is a checks if both values are true.

So for the file creation with permission mode 0644 and mask 0027, we get the final creation permissoin:

   0664  & ~(0027) 
=  0664  &   0750
=  0640

Following the math, the inverse of 0027 in binary is,

~ 000  -> 111  = 7    = 7-0 
~ 010  -> 101  = 5    = 7-2
~ 111  -> 000  = 0    = 7-7

Because inverse flips all the bits, it is the same as subtracting the value from 7. With the inverse complete, we can now do the bitwise AND of 0750 and 0644 is:

   101 101 000
&  111 100 000
--------------
   110 100 000 = 640

The mask ensures that we don't create a file with more permissions than we want. In this example, with this umask, we removed the possibility of writing from the group and read,write, execute from everyone else.

Finally, to close the file descriptor you use the close() system call, which is defined in unistd.h. It has the following function prototype:

int     close(int filde)

All open file descriptors should be closed whenever they are no longer needed. Once a program exists, the file descriptors are closed automatically.