DOCSLIB.ORG

System Calls in Unix and Windows

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
System Calls in Unix and Windows System Calls in Purpose of this Lecture Unix and Windows To familiarize you with using system calls – especially the ones to do with accessing and manipulating files. Will be of use later in the semester! Vivek Vishnumurthy 1 2 Roadmap What are System Calls? File manipulations: The services provided by the kernel to – open,close,creat,rename application programs. – read, write, lseek This interface is needed because there Directory manipulations: are things (eg: I/O instructions) that only – chdir, mkdir the kernel is allowed to perform. – link, unlink stdin, stdout, stderr 3 4 Roadmap… But first, the Shell Processes: The shell provides a user interface to – getpid,execl,fork the system. Other: – Often referred to as the “command-line – time interpreter” – But could be a GUI as well! – Egs: bash, csh, … 5 6 1 Issuing a System Call – Linux System Calls (about 300?) Normal Procedure: _llseek _newselec _sysctl accept access acct adjtimex afs_syscal alarm alloc_huge arch_prctl bdflush bind break brk cacheflush capget capset chdir chmod chown chroot clone close connect creat create_mo delete_moddup dup2 epoll_createpoll_ctl epoll_wait execve fchdir fchmod fchown fcntl fdatasync flock fork free_hugepfstat fstatfs fstatvfs fsync ftruncate futex get_kernel_get_thread_ In Unix: each system call is typically defined getcontext getdents getdomainngetdtablesigetegid geteuid getgid getgroups gethostid gethostnam getitimer getpagesizgetpeernamgetpgid getpgrp getpid getpmsg getppid getpriority getresgid getresuid getrlimit getrusage getsid getsocknamgetsockoptgettid gettimeofdagetuid gtty as a function in the standard C library. idle inb inb_p init_moduleinl inl_p insb insl insw intro inw inw_p io_cancel io_destroy io_geteven io_setup io_submit ioctl ioctl_list ioperm iopl ipc kill killpg lchown link listen llseek lock lookup_dco User process calls this function (in the normal lseek lstat madvise mincore mkdir mknod mlock mlock.2 mlockall mlockall.2 mmap mmap2 modify_ldt mount mprotect mpx mremap msgctl msgget msgop msgrcv msgsnd msync munlock munlockall munmap nanosleep nfsservctl nice obsolete C fashion) oldfstat oldlstat oldoldunamoldstat olduname open outb outb_p outl outl_p outsb outsl outsw outw outw_p pause pciconfig_i pciconfig_rpciconfig_wpersonality pipe pivot_root poll posix_fadvi prctl pread prof pselect ptrace putpmsg The function then invokes appropriate kernel pwrite query_modquotactl read readahead readdir readlink readv reboot recv recvfrom recvmsg rename rmdir sbrk sched_get_sched_get_sched_getasched_getpsched_gets service. sched_rr_gsched_setasched_setpsched_setssched_yiel security select select_tut semctl semget semop semtimedosend sendfile sendmsg sendto set_thread_setcontext setdomainnsetegid seteuid setfsgid setfsuid setgid setgroups sethostid sethostnamsetitimer setpgid setpgrp Use “man callname" for info about the call. setpriority setregid setresgid setresuid setreuid setrlimit setsid setsockoptsettimeofdasetuid setup sgetmask shmat shmctl shmdt shmget shmop shutdown sigaction sigaltstack sigblock siggetmasksigmask signal sigpause sigpending sigprocmassigqueue sigreturn sigsetmask sigsuspendsigtimedwasigvec sigwaitinfo socket socketcall socketpair ssetmask stat statfs “man –s 2 callname” in Solaris. statvfs stime stty swapoff swapon symlink sync syscall syscalls sysctl sysfs sysinfo syslog time times tkill truncate umask umount umount2 uname undocumenunimplemeunlink uselib ustat utime utimes vfork vhangup “man –S 2 callname” or just vm86 wait wait3 wait4 waitpid write writev “man callname” in Linux. 7 8 Issuing SysCall in Unix… In C#/Windows? #include <lib-file.h> “The Windows API” Lib file that has – (Comparatively) larger number of function calls. function declaration We will just concentrate on how to issue File syscall-name(); I/O calls in C#. These calls are implemented in the System.IO namespace. SysCall being called In VS .NET : see help on members of System.IO.File and System.IO.FileStream 9 10 So, in C#… File Manipulation using System.IO ; File Descriptors in Unix Namespace that has File Streams in C# method declaration method-name(); These are basically identifiers of a file opened for data access. – Support reading from files. File Method – Support writing to files. being called – Support seeking – changing position within the stream. 11 12 2 open (an exisiting file) in C/Unix open (an exisiting file) in C# using System.IO; #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> // open file 'test' for reading and writing Stream fstream = File.Open("test", System.IO.FileMode.Open, // open file 'test' for reading and writing System.IO.FileAccess.ReadWrite); int fdtest = open("test", O_RDWR); This is the option that sets file manipulation permissions – It’s the optionWhat’s that this? sets file manipulation permissions – See VS .NET help on “FileAccess” for more info Run “man 2 open” for more info 13 14 close (an already opened create (a new file) descriptor or stream) C/Unix: C#: #include <sys/types.h> using System.IO; C/Unix: C#: #include <sys/stat.h> #include <unistd.h> using System.IO; #include <fcntl.h> //close opened descriptor //create newFile with read, //create file newFile int closeResult = //close opened stream close(fdtest); //write, execute permissions Stream fstream = fstream.Close(); if(closeResult==0){ int newfd = creat(“newFile”, File.Create(“newFile"); S_IRWXU); printf("Closed successfully\n"); }else{ This is the option that sets printf("Close failed\n"); required access permissions – } Run “man creat” for more info 15 16 read (from an opened file) write (to file) #include <unistd.h> using System.IO; C/Unix: #include <unistd.h> //for write #include <string.h> //for strlen int nBytes = 100; char buf[nBytes] ; byte[] bytes = new byte[100]; char buf[] = “Hello World!\n”; //read upto ‘nBytes’ bytes //read from file into 'bytes' int nBytes = strlen(buf); // from file into buf int nRead = fstream.Read( //write ‘nBytes’ bytes from buf int nRead = read(fd, buf, bytes, 0, nBytes); bytes.Length); //to the file int nWrote = write(fd,buf,nBytes); The number of bytes Number of bytes actually read written Opened descr. on file 17 18 3 write (to file) lseek in C/Unix C#: using System.IO; Repositions read/write position in file. Useful when (say) you want to read bytes 20- String buf = “Hello World!\n”; 29 from a file. byte[] bufBytes = new byte[buf.Length]; #include <sys/types.h> int nBytes = buf.Length; for(int i=0; i<nBytes; i++) #include <unistd.h> { bufBytes[i] = (byte)buf[i]; } //offset from start //write ‘nBytes’ bytes from bufBytes to file int offset = 20; fstream.Write(bufBytes, 0, nBytes); //reposition read/write position The offset is from the start of file. For other options: run “man lseek” lseek(fd, offset, SEEK_SET); char buf[10]; Offset from start #Bytes to write //read 10 bytes starting at offset read(fd, buf, 10); Opened stream on file 19 20 Seek in C# rename in C/Unix using System.IO; Used to change name/location of a file. #include <stdio.h> //offset from start int offset = 20; //rename file ‘oldfile’ to ‘newfile’ //reposition read/write position int resRename = rename(“oldfile", fstream.Seek(offset, System.IO.SeekOrigin.Begin); “newfile"); if(resRename==0){ byte[] bufBytes = new byte[10]; printf("rename successful\n"); //read 10 bytes starting at offset }else{ fstream.Read(bufBytes, 0, bufBytes.Length); printf("rename failed\n"); } The offset is from the start of file. For other options: see help on SeekOrigin in VS .NET 21 22 Directories: Move in C# chdir (C/Unix) Used to change name/location of a file. Change working directory. using System.IO; #include <unistd.h> //rename file ‘oldfile’ to ‘newfile’ File.Move(“oldfile", “newfile"); char newDir[] = “/usr/u/vivi/courses/414”; //change working directory to newDir chdir(newDir); 23 24 4 mkdir (C/Unix) link (C/Unix) Create new directory. Creates a new link (a hard link) to an existing file. #include <unistd.h> #include <unistd.h> char newDir[] = “/usr/u/vivi/courses/414”; mkdir(newDir, S_IRWXU); link(“oldfile", “newname"); This is the option that sets Both oldfile and newname now refer access permissions – Run “man creat” for more info to the same file. 25 26 Processes: unlink (C/Unix) getpid (C/Unix) Deletes a filename. Every process has a unique process ID. getpid()returns the value of the ID of the #include <unistd.h> calling process. unlink(“newname"); #include <unistd.h> #include <sys/types.h> If newname is the last link to the file, //get process ID of the process then file itself is deleted, else the link is int pid = getpid(); deleted. Used to generate unique temp file names. 27 28 execl (C/Unix) fork (C/Unix) Replace current process image with Creates a replica child process differing new process image. Arguments to the new only in pid and ppid(parent’s pid). process #include <unistd.h> #include <sys/types.h> #include <unistd.h> In parent, fork() returns child’s pid. In child, fork() returns 0. The last argument has execl("/bin/ls", "~", NULL); to be a null pointer If newname is the last link to the file, if(fork()==0) printf(“I am the child\n”); then file itself is deleted, else the link is else deleted. printf(“I am the parent\n”); 29 30 5 time (C/Unix) stdin/stdout/stderr (Unix) Get time in seconds - #seconds elapsed Are streams for Standard Input, Output and since 00:00:00 UTC, January 1, 1970. Error, respectively. #include <time.h> Each Unix program has these three streams opened for it. time_t elapsed = time(); Eg: When printf or putchar is called, the printf(“Time
Load more

Recommended publications
  • Glibc and System Calls Documentation Release 1.0
    Glibc and System Calls Documentation Release 1.0 Rishi Agrawal <[email protected]> Dec 28, 2017 Contents 1 Introduction 1 1.1 Acknowledgements...........................................1 2 Basics of a Linux System 3 2.1 Introduction...............................................3 2.2 Programs and Compilation........................................3 2.3 Libraries.................................................7 2.4 System Calls...............................................7 2.5 Kernel.................................................. 10 2.6 Conclusion................................................ 10 2.7 References................................................ 11 3 Working with glibc 13 3.1 Introduction............................................... 13 3.2 Why this chapter............................................. 13 3.3 What is glibc .............................................. 13 3.4 Download and extract glibc ...................................... 14 3.5 Walkthrough glibc ........................................... 14 3.6 Reading some functions of glibc ................................... 17 3.7 Compiling and installing glibc .................................... 18 3.8 Using new glibc ............................................ 21 3.9 Conclusion................................................ 23 4 System Calls On x86_64 from User Space 25 4.1 Setting Up Arguements......................................... 25 4.2 Calling the System Call......................................... 27 4.3 Retrieving the Return Value......................................
    [Show full text]
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • System Calls
    System Calls What are they? ● Standard interface to allow the kernel to safely handle user requests – Read from hardware – Spawn a new process – Get current time – Create shared memory ● Message passing technique between – OS kernel (server) – User (client) Executing System Calls ● User program issues call ● Core kernel looks up call in syscall table ● Kernel module handles syscall action ● Module returns result of system call ● Core kernel forwards result to user Module is not Loaded... ● User program issues call ● Core kernel looks up call in syscall table ● Kernel module isn't loaded to handle action ● ... ● Where does call go? System Call Wrappers ● Wrapper calls system call if loaded – Otherwise returns an error ● Needs to be in a separate location so that the function can actually be called – Uses function pointer to point to kernel module implementation Adding System Calls ● You'll need to add and implement: – int start_elevator(void); – int issue_request(int, int, int); – int stop_elevator(void); ● As an example, let's add a call to printk an argument passed in: – int test_call(int); Adding System Calls ● Files to add (project files): – /usr/src/test_kernel/hello_world/test_call.c – /usr/src/test_kernel/hello_world/hello.c – /usr/src/test_kernel/hello_world/Makefile ● Files to modify (core kernel): – /usr/src/test_kernel/arch/x86/entry/syscalls/syscall_64.tbl – /usr/src/test_kernel/include/linux/syscalls.h – /usr/src/test_kernel/Makefile hello_world/test_call.c ● #include <linux/linkage.h> ● #include <linux/kernel.h> ● #include
    [Show full text]
  • Demarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P
    sysfilter: Automated System Call Filtering for Commodity Software Nicholas DeMarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P. Kemerlis Department of Computer Science Brown University Abstract This constant stream of additional functionality integrated Modern OSes provide a rich set of services to applications, into modern applications, i.e., feature creep, not only has primarily accessible via the system call API, to support the dire effects in terms of security and protection [1, 71], but ever growing functionality of contemporary software. How- also necessitates a rich set of OS services: applications need ever, despite the fact that applications require access to part of to interact with the OS kernel—and, primarily, they do so the system call API (to function properly), OS kernels allow via the system call (syscall) API [52]—in order to perform full and unrestricted use of the entire system call set. This not useful tasks, such as acquiring or releasing memory, spawning only violates the principle of least privilege, but also enables and terminating additional processes and execution threads, attackers to utilize extra OS services, after seizing control communicating with other programs on the same or remote of vulnerable applications, or escalate privileges further via hosts, interacting with the filesystem, and performing I/O and exploiting vulnerabilities in less-stressed kernel interfaces. process introspection. To tackle this problem, we present sysfilter: a binary Indicatively, at the time of writing, the Linux
    [Show full text]
  • The Evolution of the Unix Time-Sharing System*
    The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier.
    [Show full text]
  • Lab 1: Loadable Kernel Modules (Lkms)
    Lab 1: Loadable Kernel Modules (LKMs) Overview For this lab, we will be interfacing with an LCD screen using the Phytec board. This means we will be creating device drivers for our system to allow it to interact with our hardware. Since our board is running Linux­­ which is a pretty advanced operating system for most embedded devices­­ we will want to accomplish this by appending additional functionality to the working kernel. This is done using loadable kernel modules. Background Before we get too far, here is some important information we will need to know in order to interact with the Linux kernel and perform the functions we want. To write device drivers we must first understand what they are. There are three main types of device drivers; character, block, and network. In this class, we will be writing character device drivers. A character device driver is one that transfers data directly to and from a user process. This is the most common type of device driver. Character device drivers normally perform I/O in a byte stream. They can also provide additional interfaces not present in block drivers, such as I/O control commands, memory mapping, and device polling. Drivers that support a file system are known as block device drivers. Block ​ device drivers take a file system request, in the form of a buffer structure, and issue the ​ I/O operations to the disk to transfer the specified block. Block device drivers can also provide a character driver interface that allows utility programs to bypass the file system and access the device directly.
    [Show full text]
  • The UNIX Time- Sharing System
    1. Introduction There have been three versions of UNIX. The earliest version (circa 1969–70) ran on the Digital Equipment Cor- poration PDP-7 and -9 computers. The second version ran on the unprotected PDP-11/20 computer. This paper describes only the PDP-11/40 and /45 [l] system since it is The UNIX Time- more modern and many of the differences between it and older UNIX systems result from redesign of features found Sharing System to be deficient or lacking. Since PDP-11 UNIX became operational in February Dennis M. Ritchie and Ken Thompson 1971, about 40 installations have been put into service; they Bell Laboratories are generally smaller than the system described here. Most of them are engaged in applications such as the preparation and formatting of patent applications and other textual material, the collection and processing of trouble data from various switching machines within the Bell System, and recording and checking telephone service orders. Our own installation is used mainly for research in operating sys- tems, languages, computer networks, and other topics in computer science, and also for document preparation. UNIX is a general-purpose, multi-user, interactive Perhaps the most important achievement of UNIX is to operating system for the Digital Equipment Corpora- demonstrate that a powerful operating system for interac- tion PDP-11/40 and 11/45 computers. It offers a number tive use need not be expensive either in equipment or in of features seldom found even in larger operating sys- human effort: UNIX can run on hardware costing as little as tems, including: (1) a hierarchical file system incorpo- $40,000, and less than two man years were spent on the rating demountable volumes; (2) compatible file, device, main system software.
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]
  • UNIX History Page 1 Tuesday, December 10, 2002 7:02 PM
    UNIX History Page 1 Tuesday, December 10, 2002 7:02 PM CHAPTER 1 UNIX Evolution and Standardization This chapter introduces UNIX from a historical perspective, showing how the various UNIX versions have evolved over the years since the very first implementation in 1969 to the present day. The chapter also traces the history of the different attempts at standardization that have produced widely adopted standards such as POSIX and the Single UNIX Specification. The material presented here is not intended to document all of the UNIX variants, but rather describes the early UNIX implementations along with those companies and bodies that have had a major impact on the direction and evolution of UNIX. A Brief Walk through Time There are numerous events in the computer industry that have occurred since UNIX started life as a small project in Bell Labs in 1969. UNIX history has been largely influenced by Bell Labs’ Research Editions of UNIX, AT&T’s System V UNIX, Berkeley’s Software Distribution (BSD), and Sun Microsystems’ SunOS and Solaris operating systems. The following list shows the major events that have happened throughout the history of UNIX. Later sections describe some of these events in more detail. 1 UNIX History Page 2 Tuesday, December 10, 2002 7:02 PM 2 UNIX Filesystems—Evolution, Design, and Implementation 1969. Development on UNIX starts in AT&T’s Bell Labs. 1971. 1st Edition UNIX is released. 1973. 4th Edition UNIX is released. This is the first version of UNIX that had the kernel written in C. 1974. Ken Thompson and Dennis Ritchie publish their classic paper, “The UNIX Timesharing System” [RITC74].
    [Show full text]
  • Chapter 4 Introduction to UNIX Systems Programming
    Chapter 4 Introduction to UNIX Systems Programming 4.1 Introduction Last chapter covered how to use UNIX from from a shell program using UNIX commands. These commands are programs that are written in C that interact with the UNIX environment using functions called Systems Calls. This chapter covers this Systems Calls and how to use them inside a program. 4.2 What is an Operating System An Operating System is a program that sits between the hardware and the application programs. Like any other program it has a main() function and it is built like any other program with a compiler and a linker. However it is built with some special parameters so the starting address is the boot address where the CPU will jump to start the operating system when the system boots. Draft An operating system typically offers the following functionality: ● Multitasking The Operating System will allow multiple programs to run simultaneously in the same computer. The Operating System will schedule the programs in the multiple processors of the computer even when the number of running programs exceeds the number of processors or cores. ● Multiuser The Operating System will allow multiple users to use simultaneously in the same computer. ● File system © 2014 Gustavo Rodriguez-Rivera and Justin Ennen,Introduction to Systems Programming: a Hands-on Approach (V2014-10-27) (systemsprogrammingbook.com) It allows to store files in disk or other media. ● Networking It gives access to the local network and internet ● Window System It provides a Graphical User Interface ● Standard Programs It also includes programs such as file utilities, task manager, editors, compilers, web browser, etc.
    [Show full text]
  • Lecture 24 Systems Programming in C
    Lecture 24 Systems Programming in C A process is a currently executing instance of a program. All programs by default execute in the user mode. A C program can invoke UNIX system calls directly. A system call can be defined as a request to the operating system to do something on behalf of the program. During the execution of a system call , the mode is change from user mode to kernel mode (or system mode) to allow the execution of the system call. The kernel, the core of the operating system program in fact has control over everything. All OS software is trusted and executed without any further verification. All other software needs to request kernel mode using specific system calls to create new processes and manage I/O. A high level programmer does not have to worry about the mode change from user-mode to kernel-mode as it is handled by a predefined library of system calls. Unlike processes in user mode, which can be replaced by another process at any time, a process in kernel mode cannot be arbitrarily replaced by another process. A process in kernel mode can only be suspended by an interrupt or exception. A C system call software instruction generates an OS interrupt commonly called the operating system trap . The system call interface handles these interruptions in a special way. The C library function passes a unique number corresponding to the system call to the kernel, so kernel can determine the specific system call user is invoking. After executing the kernel command the operating system trap is released and the system returns to user mode.
    [Show full text]
  • Week 3: Make Your Own System Call CS444/544 System Call
    Week 3: Make Your Own System Call CS444/544 System Call • A system call is used by application (user) programs to request service from the operating system. • Switch to kernel mode.(higher privilege) • Required to ensure security. How to add a system call • Register the system call. • Declare the system call in the system header file. • Create a source file and a make file for implementing your system call. • Compile the kernel. • Create a client to test it. Steps • VM present in e:\systemcall\Lab1\ubuntu-server.vmx • For ubuntu go to /storage/systemcall/Lab1 • Log in the Virtual Machine • Username: root • Password: cspassword • Check the system kernel info (kernel version, 32/64bit) and note it down • uname -sr • Go to Linux kernel source code directory • cd /usr/src/linux Before the Lab ● Be careful to modify the kernel file ● Be aware of the naming consistency ● Don't miss any steps WHY? ○ Because you are hacking the kernel ○ Because no debug environment is set up yet Assume: Print Working Directory(pwd) is /usr/src/linux Edit arch/x86/syscalls/syscall_64.tbl to register your system call: Above x32-specific system call table around Line 323, register as 31x number, follow the same pattern 31? common yourname sys_yourname (should be 313) Edit include/linux/syscalls.h to declare your system call function: Right at the very end before #endif, add the system call function asmlinkage int sys_yourname(int num1, int num2); Create your directory(mkdir) kernel/yourname/ and create two files sys_yourname.c and Makefile inside to define your
    [Show full text]