Operating Systems Project: Device Drivers

Size: px
Start display at page:

Download "Operating Systems Project: Device Drivers"

Transcription

1 Operating Systems Project: Device Drivers Jordi Garcia and Yolanda Becerra 1 Department of Computer Architecture Universitat Politècnica de Catalunya 1. Introduction September 2012 The main aim of this project is to study the internal functions of an operating system in depth. You will learn how to modify basic data structures of an OS and improve its functionalities. In this second project, a generic Linux distribution (specifically, version 2.6) will be used and several kernel modules to add new functionalities will be implemented. When you start your PC in the laboratory, you must boot Ubuntu and the image labeled proso as usual. In [1] you can find all the documentation about Linux Kernel Modules (LKM). They basically allow kernel parts to be dynamically modified/added while Linux is still running without having to recompile or relink, as you had to do in the previous project. You will thus learn another way of modifying system code. Obviously, some functions have restricted access and some functions cannot be inserted into the kernel in this way. The most usual system changes made are to device drivers. However, to do so, it is necessary to be a privileged user as not everybody is allowed to make changes to a system. The printer driver is a typical example. Imagine a laptop that is used at home and at work; it will have several printer drivers installed on it. However, people rarely have the same printer at home as they do at work. Therefore, even though the drivers will always be installed, the physical devices (the printers) will not always be readily available. 1 This document was drawn up with the support of professors on previous courses: Julita Corbalán, Juan José Costa, Marisa Gil, Jordi Guitart, Amador Millan, Gemma Reig Silvia LLorente, Pablo Chacín and Rubén González

2 Specifically, in this project you will add a monitoring mechanism for some Linux system calls. This monitoring will be dynamically added by using a module, without the need for recompiling the Linux kernel. Once monitored, a new device will be added to allow users to access the statistics they wish to consult. It will therefore be necessary to create a driver for this device. Another module will have to be used to avoid recompiling the kernel. A summary is given below of essential concepts and of the basic code for creating modules, devices and drivers. 2. Previous concepts 2.1. Linux Kernel Modules (LKM) LKM is a Linux mechanism for dynamically adding a set of routines and data structures to a system. Each module is made up of an object file that can be dynamically mounted (inserted) on the running (executable) system using the insmod program and unmounted (removed) using the rmmod program Module definition In general, a module only needs to define an initialization function and an ending function, as can be seen in Figure 1, which shows the functions Mymodule_init and Mymodule_exit. #include <linux/module.h> #include <linux/kernel.h> #include <linux/init.h> MODULE_LICENSE( GPL ); /* * Initialize the module. */ static int init Mymodule_init(void void) { /* Initialization code */ printk(kern_debug Mymodule successfully loaded\n ); return 0; // This function returns 0 if is everything is OK // and < 0 in case of error } /* * Unload the module. */ static void exit Mymodule_exit(void void) { /* Finalization code*/ } module_init(mymodule_init); module_exit(mymodule_exit); Figure 1. Basic code of a module (mymodule.c)

3 The optional tokens init and exit are used to indicate the kernel that these functions can only be used when initializing/ending the module. The routines defined with module_init and module_exit macros are automatically executed when the module is loading and unloading, respectively. The optional keywords init and exit inform the kernel that these functions can only be used when the module is being initialized/ended. The routines defined with the macros module_init and module_exit are executed automatically when the module is loading and unloading, respectively. These macros are mandatory Defining module parameters in loading time The Linux version 2.4 and later versions allow programmers to define parameters in loading time. The interface is quite easy: module_param. Defines the parameter, its type and the access rights in the corresponding sysfs 2 file that will be created for this module to allow users to access the parameter (in our case 0, which means it will not create any files). MODULE_PARM_DESC Makes it possible to add a short description to the parameter (which can be consulted later using the modinfo command). MODULE_AUTHOR Includes the author name in the module. MODULE_DESCRIPTION Includes a description of the module. MODULE_LICENSE. Shows the type of license the module has (GPL, BSD, etc.). There is a small example below. A parameter (the PID) of the type of integer that could be modified in loading time is defined in the module s source code: #include <linux/moduleparam.h>... int pid = 1; module_param (pid, int, 0); MODULE_PARM_DESC (pid, "Process ID to monitor (default 1)");... MODULE_AUTHOR("Joe Bloggs MODULE_LICENSE ("GPL"); MODULE_DESCRIPTION("ProSO driver"); Compiling a module To compile the code in Figure 1 (saved in a file named mymodule.c), a Makefile must be created as described below: obj-m += mymodule.o 2 sysfs is a file system, generally located at /sys, used by the kernel to obtain information about devices, modules, etc. You can find further information in Chapter 2 of Linux Device Drivers, listed in the bibliography

4 all: clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean This command will result in an ELF file named mymodule.ko (ko=kernel object) Utilities that Linux has for managing modules Linux has the insmod, lsmod and rmmod commands, which install, list and remove modules from the system, respectively. Additionally, the command modprobe determines whether or not a module with the same name exists and it installs it automatically; and modinfo, which is used to look up information about the module. To load a module, use the following command: #insmod mymodule.ko In loading time, a defined parameter can be given: #insmod mymodule.ko pid=1 Also try executing the command: #modinfo mymodule.ko What does insmod do internally? The program loads the file given in the address space of the operating system and also links the remaining unresolved symbols of the file in the system symbol table It also makes it possible to change some values of the integer variables or object strings, so that the module (the driver it contains) can be configured in loading time When can a module be unloaded? A module can only be unloaded when no one is accessing it. In order to ascertain whether or not it is in use, the kernel maintains a reference counter that must be properly updated. For instance, all the functions in a module that can be accessed from other modules must increment this counter when called and decrement it when returned. To maintain this counter, the programmer can use the following macros: try_module_get(this_module): Increments the counter module_put(this_module): Decrements the counter These counters can be checked in the special device /proc/modules. If the counter is not 0, it is not possible to unload the module. Therefore it is important to maintain a consistent number of gets and puts in the counter Expressing dependencies between modules In some cases, a module needs the functionality of another module. It is therefore not possible to install the first module until the second has been installed. Linux allows

5 these dependencies to be expressed by means of the file /lib/modules/modules.dep (for instance, /lib/modules/ proso/modules.dep). For example, if module modulea requires module moduleb, this can be expressed as: /absolute_path /modula.ko: /absolute_path /modulb.ko /absolute_path /modulb.ko: It should be highlighted that the path must be an absolute path to the module s code. Thus, the command modprobe facilitates the task of loading modules when the following command is executed: #modprobe modula.ko The modules will be loaded in the proper order Devices A device is a real or virtual peripheral that users can use to perform input/output operations or to interact with the OS kernel What is a device driver? It is the group of routines and variables that handles the functions of a device (open, release, read, write, etc.), as is shown in Figure 2Error! No s'ha trobat l'origen de la referència.. Figure 2. Data structures for device management in Linux Usually, the routines that control the operation of a device require access to instructions (in/out) or addresses not allowed as an ordinary user. To be able to access these instructions and/or addresses, the code must be executed in system mode and, therefore, the driver is included in the OS code

6 How to install a device driver in the system There are two possible mechanisms: Statically, by recompiling all the system, including the new driver routines. Dynamically, by using system calls or software that make it possible to dynamically include object files in the kernel of the OS (for example, a module). You can see how a module is compiled and installed in Sections and Defining device operations To define the driver, only the group of valid operations for the device has to be defined. The possible operations to be defined are found in the header file <linux/fs.h>, in the file_operations structure. Its format is: struct file_operations { struct module *owner owner; loff_t(*llseek) (struct file *, loff_t, int); ssize_t(*read read) (struct file *, char user *, size_t, loff_t *); ssize_t(*aio_read) (struct kiocb *, char user *, size_t, loff_t); ssize_t(*write) (struct file *, const char user *, size_t, loff_t *); ssize_t(*aio_write) (struct kiocb *, const char user *, size_t, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open open) (struct inode *, struct file *); int (*flush) (struct file *); int (*release release) (struct inode *, struct file *); int (*fsync) (struct file *, struct dentry *, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); ssize_t(*readv) (struct file *, const struct iovec *, unsigned long, loff_t *); ssize_t(*writev) (struct file *, const struct iovec *, unsigned long, loff_t *); ssize_t(*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void user *); ssize_t(*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area) (struct file *, unsigned long, unsigned long, unsigned long, unsigned long); You will use the open, release (which corresponds to close), read and ioctl operations. The open function makes the device available to the program and the release function ends access. They both return 0 if everything is correct and <0 in the case of error. The arguments of the read function are the following: the user s

7 buffer where the read characters are stored, the number of characters to read size, and an offset in/out parameter that shows the current position of the read/write pointer before it is read, and the current position after it is read. The call returns the number of bytes read, 0 if it has reached the end of the file, or <0 if an error has occurred. The ioctl function returns 0 if everything is correct or <0 if an error has occurred. The first field in the file_operations structure, named owner, is used when the driver is installed as a module. If defined, this field saves the programmer the task of explicitly handling the reference counter of the driver s module (as explained in Section 2.1.6): when using the macro THIS_MODULE, the kernel automatically maintains the reference counter and it is not necessary to use the functions try_module_get and module_put 3. There are also definitions for the structures struct inode and struct file in this header file. In order to make the code reading easier, the required fields of this structure might be tagged such as those listed below: struct file_operations mymod_fops = { } owner: THIS_MODULE, read: mymod_read, ioctl: mymod_ioctl, open: mymod_open, release: mymod_release, Note that this syntax is not C standard, but an extension of the GNU compiler. In the case this compiler is not be available, our old friend NULL will have to be used in the fields in which initialization is unwanted. Finally, it must be pointed out that the only operations required are those that the driver will have Device identification How does the system know that a specific system call references a specific driver? By default, it does not know. When the driver is installed, an identifier must be explicitly specified. This identifier is unique and it is formed by two integers: the major and the minor (traditionally the major was used to identify the device type and the minor to identify the subtype). This operation is called registering the driver and is performed in two steps: first, the identifier is reserved, and then the operations are associated with this identifier. To generate an identifier for a driver, use the MKDEV macro, which, given a major and a minor, fills the type dev_t structure with the corresponding identifier. dev_t MKDEV(unsigned int major, unsigned int minor); A definition of the structure dev_t can be found in the header file 3 Keep in mind that a driver is considered in use since the device is opened until it is released

8 <linux/types.h>. Furthermore, when a new device is added to the system, it is also necessary to specify the major and minor of the corresponding device driver that manages it. Thus, each time an operation is performed on a device, the system uses this identifier to find the operations of its driver How to register a device driver The first step in registering a device driver is to reserve its identifier. Using the register_chrdev_region function defined in the header file <linux/fs.h>, it is possible to reserve a range of device drivers identifiers: int register_chrdev_region (dev_t first, unsigned int count, const char *name); The arguments are the first identifier of the region to be reserved (first), which must be previously generated from a major and a minor using the MKDEV macro; the number of identifiers to be reserved (count); and the name of the device (name), which will be shown in /proc/devices. A negative return value means an error has occurred. This function reserves count identifiers, all of which have the same major (from the parameter first) and consecutive minors (starting with the minor from the parameter first) 4. To release the driver s identifiers and allow them to be used in the future, the unregister_chrdev_region function can be used. void unregister_chrdev_region(dev_t first, unsigned int count); The arguments are the region s first identifier (first) and the number of identifiers in the region (count). Once the identifiers have been reserved, they must be associated with the driver s specific operations. To do so, a type cdev structure is used. This structure is defined in the header file <linux/cdev.h>. First, it is necessary to define a new structure: struct cdev *my_cdev; It is then necessary to reserve the memory space for the structure using the following 4 It is also possible to let the system assign all the identifiers for a driver, without passing the first identifier in the range, but this requires using the alloc_chrdev_region function instead of register_chrdev_region. For further details about this alternative function, see Chapter 3 of Linux Device Drivers, cited in the bibliography

9 function 5 : struct cdev *cdev_alloc(); Two of its fields must then be initialized, namely, the owner field, used by the system to maintain a counter of references to the structure and that must be initialized using the macro THIS_MODULE; and the ops field, which must be initialized using the structure file_operations that contains the specific operations for the driver. Finally, this structure must be attached to the device structures registered in the system using the following function: int cdev_add(struct cdev *dev, dev_t num, unsigned int count); The parameters of this function are: the structure that contains the operations of the driver (dev), the first identifier of the region (num) and the number of drivers of the region which are to be associated with these operations (count). This function returns a negative value if any errors occur. Until this function is successfully executed, the driver will not be visible to the system and, therefore, it will not be possible to use its functions. Below is a short example in which a new cdev is declared and initialized: struct cdev *my_cdev; my_cdev = cdev_alloc(); my_cdev->owner = THIS_MODULE; my_cdev->ops = &my_fops; /* my_fops is a static structure of type file_operations previously initialized with the operations of the driver */ cdev_add(my_cdev, dev, ndev); /* check of errors must be made */ When the driver is no longer in use, its cdev structure must be removed from the system: void cdev_del(struct cdev *dev); How to select the major and the minor The device driver identifier is derived from the major and the minor. Therefore, a combination that no other device is using is required. There is a list of all the installed device drivers with their major 6 in the file /proc/devices. Although Linux version If the variable of type cdev is defined statically rather than as a pointer, the cdev_init must be used instead of the cdev_alloc function. You will find the definition of this function in Linux Device Drivers, cited in the bibliography. 6 In the previous version of Linux, the major was used to identify the device driver and the minor was only used internally by the driver to distinguish between the different device types that it could manage. In version 2.6 and the following versions, both numbers (major and minor) are needed to identify the operations associated with a device. However, the format in /proc/devices still only shows the major of the driver

10 allows different drivers to have the same major, a major currently not assigned can be selected to obtain a new major-minor combination. Thus, any minor can work with the confidence that the combination is not already in use. There is an option that frees the programmer from the task of selecting these numbers, whereby the system is told to dynamically reserve a rank of driver identifiers (which implicitly selects the majors and the minors in the region 7 ). Note that in this case, the driver identifiers can vary each time the driver is installed: this behavior must be considered when the devices are added How the major and the minor are recognized inside the driver Using the following macros: int MAJOR(dev_t dev); int MINOR(dev_t dev); The value of the parameter dev is extracted from the inode (one of the parameters that all the driver s operations receive: Section Error! No s'ha trobat l'origen de la referència.) How a file is associated with a device The devices are visible from the filesystem (by default the files in /dev/* are devices). They can be created using the system call mknod. #mknod file type major minor The arguments are: the file, which identifies the file that will be used as a device; the type (a c to create a character device); the major and the minor, which are integers that make it possible to identify the device in the system (see Section Error! No s'ha trobat l'origen de la referència. for further details; any minor can be used to begin). To see the various devices already existing in the system, check the file /proc/devices, in which the available devices (major and registered names) are grouped by device type. Once the device file is created, the functionalities (i.e. which operations the system allows for the device) of this file must be defined. This is done by using the device driver How users access the device Users can access the device using the usual file system calls: open, close, read, write, ioctl. 7 For further details, see Chapter 3 of Linux Device Drivers, cited in the bibliography

11 The only of these system calls that is really dependent on the peripheral is ioctl, which allows users to perform specific operations on the peripheral by combining its last two arguments Linux How to find the Linux source code The directory /usr/src/linux contains the system s source code. The headers related to the system version are in /usr/src/linux/include. The various routines and structures used by Linux to manage processes can be found in Chapter 3 of [2]: for_each_process, find_task_by_pid, etc. (see Symbols By symbols, we mean variable names and routine names. Symbols from an object file can be consulted using the nm command. Another kind of symbol is that defined using #define, such as the macro current, which returns a pointer struct task struct that references the control data of the running process. This structure is known as the PCB (Process Control Block). See The Linux symbol table Linux exports a set of symbols so that they can be used and referenced from modules. For each exported symbol (variable, routine, etc.) the system keeps the name and memory address where it is allocated (system logical address) in a table. This symbol table is created in compilation time, since it is necessary to have the name of the symbol and its address. To export a symbol, the macro EXPORT_SYMBOL(symbol_name) must be used and the kernel recompiled (an example can be seen at As modules are part of the kernel, they can also export symbols using this macro. A definition of the system s architecture-independent symbol table can be found in the file kernel/ksyms.c. The Intel architecture-dependent exported symbols can be found in the file arch/i386/kernel/i386_ksyms.c How to ascertain the contents of the system s symbol table There are two different ways: Reading the device /proc/ksyms Using the command ksyms -a

12 What must internal system routines return? Who receives this information? The Linux convention states that a negative value (< 0) is returned when an error occurs. Otherwise, a non-negative value (>=0), is returned. The type of error is the absolute value of the returned code. It is necessary to find out its meaning in the header file <sys/errno.h> What action should be taken when an internal system routine returns an error? What type of error should be returned? If we do not have a specific treatment, it should be returned the same error that has already given us back the system routine User space and system space The system differentiates between two address translation functions when it is running. Depending on the processor execution mode, one or another will be used. Usually, there is a unique translation function for the system code and a specific translation function for each running process. This mechanism guarantees the system security, since users cannot change system data from its applications or between applications because they cannot access other application address spaces. Likewise, the memory access mechanism depends on the execution mode. If it is necessary to access the user address space (to pass parameters for system calls, for example) when running in system mode, special instructions will be needed to tell the processor that the user address space must be used, even if the system mode is on. Remember that you will have to check in each case if it is possible for the user and the system space to copy this information, as you did in Project Operations to copy data between address spaces Basically, there are two operations, which are declared in <asm-i386/uaccess.h>: unsigned long copy_from_user(void *to, const void *from, unsigned long count); To copy from the user mode to system mode. unsigned long copy_to_user(void *to, const void *from, unsigned long count); To copy from the system mode to user mode. See the parameters and return values at How printk works printk is the routine that can be used inside the kernel to write information in the computer console. However, its (excessive) use is discouraged. The format and parameters that it uses are a limited version of that used for the printf routine from the C library. It is a line-buffered writing function. This means that it will not write data until it does not find a line jump. It must be highlighted that printk has a special feature: the first characters of a string

13 are interpreted as the message priority that is to be written. The format of this information is: printk ("<N>Goodbye cruel world\n"); printk (KERN_EMERG "Goodbye cruel world\n"); where N is a number between 0 and 7. Depending on the priority level, the message appears in a different place: the computer console, a log file (for example, /var/log/messages or /var/log/kern.log), etc. The log file name depends on the system configuration (/etc/syslog.conf). Some macros such as KERN_EMERG for defining different priorities can be found in the file <linux/kernel.h>. If the priority is lower than console_loglevel, the message is printed to the console. If syslogd and klogd are running, the message is also written in the log file, regardless of whether or not it is written to the console. All these kernel messages are kept on a structure called the kernel ring buffer, which can be accessed using the dmesg command. The size of this buffer is limited, so old messages are removed to make room for new ones (a kind of circular queue). More information can be found in the appendix of this document or by using the man command: man dmesg man syslogd man syslog.conf 3. Description of work In this project, you have to modify the system to take usage statistics. Current OSes have different ways to store statistics about them, so that problems can be easily identified and the appropriate actions taken. In our particular case, the task will be to find out the system s mean response time by focusing on system calls. To do so, the entry point of each system call must be modified introducing new code (instrumentation). We will keep information for the following calls: open, write, clone, close and lseek. The information needed for each type can be summarized by: Number of times the call is initiated Number of times it ends correctly Number of times it ends incorrectly The time the call is running By adding this instrumentation to each system call, the system may be a little slower. You are therefore to implement this instrumentation dynamically so that it can be enabled or disabled. To do this, the Linux system call table will be intercepted and each function to measure up, replaced for a local function. This local function will check the time it takes the old function to execute. This local function will have the same interface than the corresponding system call (you can see this interface on the Linux source code)

14 To sum up, you will have to implement two modules: Module 1 to intercept system calls and measure the time spent. Module 2 to access system statistics Module 1: Intercepting and measuring This module will intercept the symbols table (modify the system call table), insert the instrumentation functions when the module is loaded into the system (by enabling instrumentation) and remove them when unloading it. The instrumentation functions will be in the module and they will update the system call counters for the current process. You can use the mechanism explained in the section How to measure time for measuring times. From the system call table, the original functions will be replaced by those to be monitored for the routines created. These monitoring routines must (see Figure 3): 1. Mark the beginning of the system call 2. Execute the original system call 3. Calculate the total running time and obtain the call result Running program Your routine is executed: time check Original system call System call System call return The original system call ends. Time check and total duration calculated. Figure 3. Diagram of system call interceptions Intercepting the system call table The system call table is called sys_call_table and it is a table of function pointers. Thus, if the module defines: extern void * sys_call_table[];

15 a symbol will be obtained that references the system call table (see Intercepting system calls After the system call table has been obtained, only the functions to be monitored need to be kept. Below is an example of where the variable is stored: sys_open_old = sys_call_table[pos_syscall_open]; From this time on, the variable sys_open_old will contain a pointer to the original open system call Modifying the system call table The table will obviously be modified in the same way. If a function to monitor the open called sys_open_local has been defined, it will only be necessary to enable the following: sys_call_table[pos_syscall_open] = sys_open_local; Headers of the system call to trace As an example, you can find below the headers of the system calls to trace in modul 2. Notice that the kernel headers are different from the user (system calls headers): long sys_open(const char user * filename, int flags, int mode); long sys_close(unsigned int fd); ssize_t sys_write(unsigned int fd, const char user * buf, size_t count) ; off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin) ; int sys_clone(struct pt_regs regs) ; To obtain the other system call headers you can see: Where to maintain statistics In kernel 2.6, the management of the PCB is different to version 2.4 and is therefore different to the ZeOS. In version 2.6 and the following versions, it was decided to split the PCB into two components: task_struct and thread_info

16 current_thread_info() current Figure 4. Sharing of two pages by the kernel stack and the thread_union The task_struct contains the process information, such as the open files and a pointer to the thread_info. The thread_info is the structure that shares the memory space with the kernel stack. It contains the thread s execution state and a pointer to the task_struct. A definition can be seen at A definition of the thread_union (the convergence of the thread_info and the stack) is at Also see Figure 4. The macro current must be used to obtain the address of the task_struct. The routine current_thread_info() must be used to obtain the base address of the thread_info. As the statistics require little space, they will be stored just above the structure thread_info so that they can easily be associated with the process. To do so, a new structure called my_thread must be created. It will contain the structure thread_info and the statistics for the process (see Figure 5)

17 Figure 5. Where statistics are stored For each process, it must be determined whether or not its statistics have been initialized. Notice that to create a new process, the kernel will reuse the same data structures previously associated with a dead process. Therefore, this structure can still store the statistics from the previous process. It must be determined whether or not statistics have been initialized. Therefore, an additional field can be defined in the data structure to store the PID of the process associated with the data currently stored. If the PID does not match the current process PID, the statistics have not been initialized and, therefore, this must be done and the PID updated How to measure time You can use the proso_get_cycles function for measuring time. It is implemented as follows: #define proso_rdtsc(low,high) \ asm volatile ("rdtsc" : "=a" (low), "=d" (high)) static inline unsigned long long proso_get_cycles (void) { unsigned long eax, edx; } proso_rdtsc(eax, edx); return ((unsigned long long) edx << 32) + eax; Other restrictions Each process must have its own counters for the system calls, so they will have to be reset to zero for each new process. As a final requirement, you must check that everything works properly. Thus, when the module is uninstalled from the system, it will print the PID s statistics on the screen that will have been entered as an argument when the module was inserted. It is necessary to prevent the module from being unloaded when there is a process with an intercepted call (you can use try_module_get and module_put, as explained in Section 2.1.6)

18 Tests To check that the module is working properly, a number of tests must be run to show this. Below is a skeleton of the tests: Begin the test. Print a start message. Print the PID of the current process and block the process until a key is pressed. (Load the module with the PID of the test.) Press a key and continue with the test. Check that all the system calls have been monitored. Print an end message to finish the test. Block the process until a key is pressed. (Download the module and print the process statistics.) Check that the results belong to the test. End the test Module 2: Accessing system information The main aim of this project is to build a module that will make it possible to access the information stored in the previous delivery. Using the previous module, it was possible to monitor all the processes created in the system. Using this module, a new device will be created to access this information. To create this device, you must select a major and a minor to identify the driver, which will be used to register it and to create the file that will represent the device in the file system. This module allows the process and the system call to be selected from which information is to be obtained (even when all the processes and the five system calls are being monitored). A new device must be created that will make it possible to perform the following operations: ssize_t read (struct file *f, char user *buffer, size_t s, loff_t *off); int ioctl (struct inode *i, struct file *f, unsigned int arg1, unsigned long arg2); int open (struct inode *i, struct file *f); int release (struct inode *i, struct file *f); open. The device can only be opened one process at a time and only by the user root (uid==0). read. A read on this device will return a structure to the user space (buffer) with information about the current monitored system call for the process currently being monitored. Users should create the structure before executing the read system call. The number of bytes to be read will be the minimum before the s parameter and the sizeof(struct_info). ioctl. Users will be able to modify the device s settings using this call (selected process and system call, etc.). release. This call will deallocate the use of the device

19 By default, the read system call obtains the statistics of the open system call for the process that opened the device. The structure that will be returned to the user is of the type shown below: struct t_info { } int num_entries; int num_exits_ok; int num_exits_error; unsigned long long total_time; In order to control the behavior of this new device using the ioctl call, the following parameters (the values in brackets are constant values) must be defined: CHANGE_PROCESS (arg1 = 0). The third parameter (arg2) indicates, by reference, the identifier of the process that is to be analyzed. If the pointer is NULL (zero), this means that once again the target process for the read system call is the one that opened the device. If the required process does not exist, the system call must return an error. CHANGE_SYSCALL (arg1 = 1). This makes it possible to change the target system call for the read system call. The meaning of the third parameter (arg2) is: OPEN (0) WRITE (1) LSEEK (2) CLOSE (3) CLONE (4) RESET_VALUES (arg1 = 2). This resets the statistics of the process currently being analyzed. RESET_VALUES_ALL_PROCESSES (arg1=3). This resets the statistics of all processes. The system call will return a zero if everything worked properly, and < 0 if an error occurred (the corresponding error code will be displayed). 4. Dynamic monitoring The aim in this stage of the project is to add more dynamism to the instrumentation mechanisms than have been explained so far. To do so, the modules created must be modified

20 4.1. Changes in Module 1 The monitoring of system calls is to be dynamically activated/deactivated. Thus, the new behavior will be as follows: By default, all five system calls will be monitored, as before. Two new functions will be added to make it possible to activate/deactivate the monitoring of system calls. Module 2 will access these two new functions. The addresses of the system calls should be kept on a table (penalties will be imposed if such a table is not implemented) Changes in Module 2 To allow users to activate/deactivate the monitoring of a system call, the functionality of the ioctl function for the device must be extended using the new functions added to Module 1. Enable and disable the system calls to implement selectively. The system call ioctl must be modified to implement two new operations: o o ENABLE SYS CALL (arg1 = 4 and arg2 = num). Enables the instrumentation of the system call num (or all of them if num is a negative number). DISABLE SYS CALL (arg1 = 5 and arg2 = num). Disables the instrumentation of the system call num (or all of them if num is a negative number). Users must be able to easily introduce the type of the call to be implemented, such as by using constants. 5. Deliverables You should deliver all of the source files (including Makefiles) you have created and the test suite you used to test the modules. Additionally, you must submit a README file describing your test suite and the instructions to execute it

21 6. References [1] Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman: Linux Device Drivers, third Edition, February [2] Daniel P. Bovet, Marco Cesati: Understanding the Linux Kernel. O Reilly. November [3] 7. Appendix: how to export the sys_call_table symbol In the kernel you will use in the laboratory, the symbol sys_call_table will already have been exported. However, if you want to test your project at home, follow the steps below to generate a new kernel image (with the name linux.2.6.xx-proso, where xx is the subversion you have installed). 1. Go to the kernel source code directory (assume to be /usr/src/linux). # cd /usr/src/linux 2. Modify the file arch/i386/kernel/i386_ksyms.c by adding the following lines: extern void * sys_call_table[]; EXPORT_SYMBOL(sys_call_table); 3. Edit the Makefile to modify the variable EXTRAVERSION, to set the image name: # vi Makefile... EXTRAVERSION=-proso Use the current configuration file from the /boot directory. # cp /boot/config-2.6.xxxx.config 5. Prepare the environment to compile the kernel. # make oldconfig 6. Recompile the kernel. # make 7. Recompile the modules. # make modules_install

22 8. Install the kernel image (vmlinuz-2.6.xxx-proso) and the symbols (System.map-2.6.xx-proso). # make install 9. Generate a boot file with the required modules (otherwise, the system will not boot). # mkinitramfs -o /boot/initrd.img-2.6.xxx-proso 2.6.XXX-proso 10. Modify the grub s boot file, /boot/grub/menu.lst to add the new image. # vi /boot/grub/menu.lst 11. Modify the following fields to point to the new image and the new initrd file: title kernel initrd

Linux Driver Devices. Why, When, Which, How?

Linux Driver Devices. Why, When, Which, How? Bertrand Mermet Sylvain Ract Linux Driver Devices. Why, When, Which, How? Since its creation in the early 1990 s Linux has been installed on millions of computers or embedded systems. These systems may

More information

Linux Firewall Lab. 1 Overview. 2 Lab Tasks. 2.1 Task 1: Firewall Policies. Laboratory for Computer Security Education 1

Linux Firewall Lab. 1 Overview. 2 Lab Tasks. 2.1 Task 1: Firewall Policies. Laboratory for Computer Security Education 1 Laboratory for Computer Security Education 1 Linux Firewall Lab Copyright c 2006-2011 Wenliang Du, Syracuse University. The development of this document is funded by the National Science Foundation s Course,

More information

Linux LKM Firewall v 0.95 (2/5/2010)

Linux LKM Firewall v 0.95 (2/5/2010) 600/650.424 Network Security Linux LKM Firewall 1 1 Overview Linux LKM Firewall v 0.95 (2/5/2010) The learning objective of this project is for you to understand how firewalls work by designing and implementing

More information

Operating Systems. 12. Devices. Paul Krzyzanowski. Rutgers University. Spring 2015. 3/9/2015 2014-2015 Paul Krzyzanowski

Operating Systems. 12. Devices. Paul Krzyzanowski. Rutgers University. Spring 2015. 3/9/2015 2014-2015 Paul Krzyzanowski Operating Systems 12. Devices Paul Krzyzanowski Rutgers University Spring 2015 3/9/2015 2014-2015 Paul Krzyzanowski 1 Devices Block devices: disk drives, flash memory Addressable blocks (suitable for caching)

More information

Kernel Hacking. Introduction to Linux Kernel 2.6 How to write a Rootkit. Maurice Leclaire. January 19, TumFUG Linux / Unix get-together

Kernel Hacking. Introduction to Linux Kernel 2.6 How to write a Rootkit. Maurice Leclaire. January 19, TumFUG Linux / Unix get-together Kernel Hacking Introduction to Linux Kernel 2.6 How to write a Rootkit Maurice Leclaire TumFUG Linux / Unix get-together January 19, 2011 Why hacking the kernel? Understanding the Linux kernel Fixing bugs

More information

User-level processes (clients) request services from the kernel (server) via special protected procedure calls

User-level processes (clients) request services from the kernel (server) via special protected procedure calls Linux System Call What is System Call? User-level processes (clients) request services from the kernel (server) via special protected procedure calls System calls provide: An abstraction layer between

More information

Linux Kernel Rootkit : Virtual Terminal Key Logger

Linux Kernel Rootkit : Virtual Terminal Key Logger Linux Kernel Rootkit : Virtual Terminal Key Logger Jeena Kleenankandy Roll No. P140066CS Depatment of Computer Science and Engineering National Institute of Technology Calicut jeena p140066cs@nitc.ac.in

More information

W4118 Operating Systems. Junfeng Yang

W4118 Operating Systems. Junfeng Yang W4118 Operating Systems Junfeng Yang Outline Linux overview Interrupt in Linux System call in Linux What is Linux A modern, open-source OS, based on UNIX standards 1991, 0.1 MLOC, single developer Linus

More information

System Calls Related to File Manipulation

System Calls Related to File Manipulation KING FAHD UNIVERSITY OF PETROLEUM AND MINERALS Information and Computer Science Department ICS 431 Operating Systems Lab # 12 System Calls Related to File Manipulation Objective: In this lab we will be

More information

Lab 6: Building Your Own Firewall

Lab 6: Building Your Own Firewall CS498 Systems and Networking Lab Spring 2012 Lab 6: Building Your Own Firewall Instructor: Matthew Caesar Due: Firewalls are widely deployed technologies for protecting networks from unauthorized access

More information

TN203. Porting a Program to Dynamic C. Introduction

TN203. Porting a Program to Dynamic C. Introduction TN203 Porting a Program to Dynamic C Introduction Dynamic C has a number of improvements and differences compared to many other C compiler systems. This application note gives instructions and suggestions

More information

Lecture 03 Bits, Bytes and Data Types

Lecture 03 Bits, Bytes and Data Types Lecture 03 Bits, Bytes and Data Types In this lecture Computer Languages Assembly Language The compiler Operating system Data and program instructions Bits, Bytes and Data Types ASCII table Data Types

More information

Project No. 2: Process Scheduling in Linux Submission due: April 28, 2014, 11:59pm

Project No. 2: Process Scheduling in Linux Submission due: April 28, 2014, 11:59pm Project No. 2: Process Scheduling in Linux Submission due: April 28, 2014, 11:59pm PURPOSE Getting familiar with the Linux kernel source code. Understanding process scheduling and how different parameters

More information

The Linux Kernel Module Programming Guide

The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright 2001 Peter Jay Salzman 2005 01 23 ver 2.6.1 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the

More information

Migration of Process Credentials

Migration of Process Credentials C H A P T E R - 5 Migration of Process Credentials 5.1 Introduction 5.2 The Process Identifier 5.3 The Mechanism 5.4 Concluding Remarks 100 CHAPTER 5 Migration of Process Credentials 5.1 Introduction Every

More information

Project Adding a System Call to the Linux Kernel

Project Adding a System Call to the Linux Kernel 74 Chapter 2 Operating-System Structures 2.15 Why is a just-in-time compiler useful for executing Java programs? 2.16 What is the relationship between a guest operating system and a host operating system

More information

REAL TIME OPERATING SYSTEM PROGRAMMING-II: II: Windows CE, OSEK and Real time Linux. Lesson-12: Real Time Linux

REAL TIME OPERATING SYSTEM PROGRAMMING-II: II: Windows CE, OSEK and Real time Linux. Lesson-12: Real Time Linux REAL TIME OPERATING SYSTEM PROGRAMMING-II: II: Windows CE, OSEK and Real time Linux Lesson-12: Real Time Linux 1 1. Real Time Linux 2 Linux 2.6.x Linux is after Linus Torvalds, father of the Linux operating

More information

Linux Kernel Architecture

Linux Kernel Architecture Linux Kernel Architecture Amir Hossein Payberah payberah@yahoo.com Contents What is Kernel? Kernel Architecture Overview User Space Kernel Space Kernel Functional Overview File System Process Management

More information

Jorix kernel: real-time scheduling

Jorix kernel: real-time scheduling Jorix kernel: real-time scheduling Joris Huizer Kwie Min Wong May 16, 2007 1 Introduction As a specialized part of the kernel, we implemented two real-time scheduling algorithms: RM (rate monotonic) and

More information

Lab 2 : Basic File Server. Introduction

Lab 2 : Basic File Server. Introduction Lab 2 : Basic File Server Introduction In this lab, you will start your file system implementation by getting the following FUSE operations to work: CREATE/MKNOD, LOOKUP, and READDIR SETATTR, WRITE and

More information

A Comparison of the Linux and Windows Device Driver Architectures

A Comparison of the Linux and Windows Device Driver Architectures A Comparison of the Linux and Windows Device Driver Architectures Melekam Tsegaye Rhodes University, South Africa g98t4414@campus.ru.ac.za Richard Foss Rhodes University, South Africa r.foss@ru.ac.za Abstract:

More information

CS 377: Operating Systems. Outline. A review of what you ve learned, and how it applies to a real operating system. Lecture 25 - Linux Case Study

CS 377: Operating Systems. Outline. A review of what you ve learned, and how it applies to a real operating system. Lecture 25 - Linux Case Study CS 377: Operating Systems Lecture 25 - Linux Case Study Guest Lecturer: Tim Wood Outline Linux History Design Principles System Overview Process Scheduling Memory Management File Systems A review of what

More information

Load Balancing - Single Multipath Route HOWTO

Load Balancing - Single Multipath Route HOWTO Load Balancing - Single Multipath Route HOWTO Shakthi Kannan, shaks_wants_no_spam_at_shakthimaan_dot_com January 5, 2007 Revision: 1.2 Abstract This documentation provides the steps to setup load-balancing

More information

Content. Introduction and History. File I/O. The File System. Shell Programming. Standard Unix Files and Configuration. Processes

Content. Introduction and History. File I/O. The File System. Shell Programming. Standard Unix Files and Configuration. Processes Content Introduction and History File I/O The File System Shell Programming Standard Unix Files and Configuration Processes Programs are instruction sets stored on a permanent medium (e.g. harddisc). Processes

More information

Exceptions in MIPS. know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine

Exceptions in MIPS. know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine 7 Objectives After completing this lab you will: know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine Introduction Branches and jumps provide ways to change

More information

System Calls and Standard I/O

System Calls and Standard I/O System Calls and Standard I/O Professor Jennifer Rexford http://www.cs.princeton.edu/~jrex 1 Goals of Today s Class System calls o How a user process contacts the Operating System o For advanced services

More information

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

More information

BOSS MOOL GNU/Linux User Manual

BOSS MOOL GNU/Linux User Manual BOSS MOOL GNU/Linux User Manual 1 Contents Chapter 1 Introduction...3 1.1 What is BOSS MOOL GNU/Linux?...3 1.1.1 INSTALL...3 1.1.2 BOSS MOOL GNU/Linux Components...4 1.2 BOSS MOOL GNU/Linux Licensing...

More information

The Linux Virtual Filesystem

The Linux Virtual Filesystem Lecture Overview Linux filesystem Linux virtual filesystem (VFS) overview Common file model Superblock, inode, file, dentry Object-oriented Ext2 filesystem Disk data structures Superblock, block group,

More information

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C Embedded Systems A Review of ANSI C and Considerations for Embedded C Programming Dr. Jeff Jackson Lecture 2-1 Review of ANSI C Topics Basic features of C C fundamentals Basic data types Expressions Selection

More information

Assignment0: Linux Basics and /proc

Assignment0: Linux Basics and /proc Assignment0: Linux Basics and /proc CS314 Operating Systems This project was adapted from Gary Nutt s Excellent Book Kernel Projects for Linux published by Addison-Wesley 2001. You will learn several important

More information

Operating Systems and Networks

Operating Systems and Networks recap Operating Systems and Networks How OS manages multiple tasks Virtual memory Brief Linux demo Lecture 04: Introduction to OS-part 3 Behzad Bordbar 47 48 Contents Dual mode API to wrap system calls

More information

Illustration 1: Diagram of program function and data flow

Illustration 1: Diagram of program function and data flow The contract called for creation of a random access database of plumbing shops within the near perimeter of FIU Engineering school. The database features a rating number from 1-10 to offer a guideline

More information

The C Programming Language course syllabus associate level

The C Programming Language course syllabus associate level TECHNOLOGIES The C Programming Language course syllabus associate level Course description The course fully covers the basics of programming in the C programming language and demonstrates fundamental programming

More information

Threads Scheduling on Linux Operating Systems

Threads Scheduling on Linux Operating Systems Threads Scheduling on Linux Operating Systems Igli Tafa 1, Stavri Thomollari 2, Julian Fejzaj 3 Polytechnic University of Tirana, Faculty of Information Technology 1,2 University of Tirana, Faculty of

More information

Assignment 5: Adding and testing a new system call to Linux kernel

Assignment 5: Adding and testing a new system call to Linux kernel Assignment 5: Adding and testing a new system call to Linux kernel Antonis Papadogiannakis HY345 Operating Systems Course 1 Outline Introduction: system call and Linux kernel Emulators and Virtual Machines

More information

Storage Classes CS 110B - Rule Storage Classes Page 18-1 \handouts\storclas

Storage Classes CS 110B - Rule Storage Classes Page 18-1 \handouts\storclas CS 110B - Rule Storage Classes Page 18-1 Attributes are distinctive features of a variable. Data type, int or double for example, is an attribute. Storage class is another attribute. There are four storage

More information

File System Implementation II

File System Implementation II Introduction to Operating Systems File System Implementation II Performance, Recovery, Network File System John Franco Electrical Engineering and Computing Systems University of Cincinnati Review Block

More information

Chapter 12 File Management

Chapter 12 File Management Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Roadmap Overview File organisation and Access

More information

Chapter 12 File Management. Roadmap

Chapter 12 File Management. Roadmap Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Overview Roadmap File organisation and Access

More information

Audit Trail Administration

Audit Trail Administration Audit Trail Administration 0890431-030 August 2003 Copyright 2003 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent Computer

More information

Future Technology Devices International Ltd. Mac OS X Installation Guide

Future Technology Devices International Ltd. Mac OS X Installation Guide Future Technology Devices International Ltd. Mac OS X Installation Guide I Mac OS X Installation Guide Table of Contents Part I Welcome to the Mac OS X Installation Guide 2 Part II VCP Drivers 3 1 Installing

More information

Keil C51 Cross Compiler

Keil C51 Cross Compiler Keil C51 Cross Compiler ANSI C Compiler Generates fast compact code for the 8051 and it s derivatives Advantages of C over Assembler Do not need to know the microcontroller instruction set Register allocation

More information

Mouse Drivers. Alan Cox. alan@redhat.com

Mouse Drivers. Alan Cox. alan@redhat.com Mouse Drivers Alan Cox alan@redhat.com Mouse Drivers by Alan Cox Copyright 2000 by Alan Cox This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General

More information

1 Abstract Data Types Information Hiding

1 Abstract Data Types Information Hiding 1 1 Abstract Data Types Information Hiding 1.1 Data Types Data types are an integral part of every programming language. ANSI-C has int, double and char to name just a few. Programmers are rarely content

More information

Introduction. What is an Operating System?

Introduction. What is an Operating System? Introduction What is an Operating System? 1 What is an Operating System? 2 Why is an Operating System Needed? 3 How Did They Develop? Historical Approach Affect of Architecture 4 Efficient Utilization

More information

The Linux Kernel Device Model

The Linux Kernel Device Model The Linux Kernel Device Model Patrick Mochel Open Source Development Lab mochel@osdl.org Abstract Linux kernel development follows a simple guideline that code should be only as complex as absolutely necessary.

More information

Chapter 8. Arithmetic in C++

Chapter 8. Arithmetic in C++ Christian Jacob Chapter 8 Arithmetic in C++ 8.1 The C++ Vocabulary 8.2 Variables and Types 8.2.1 Data Objects 8.2.2 Variables 8.2.3 Declaration of Variables 8.3 Elementary C++ Data Types 8.3.1 Integers

More information

Format String Vulnerability. printf ( user input );

Format String Vulnerability. printf ( user input ); Lecture Notes (Syracuse University) Format String Vulnerability: 1 Format String Vulnerability printf ( user input ); The above statement is quite common in C programs. In the lecture, we will find out

More information

Toasterkit - A NetBSD Rootkit. Anthony Martinez Thomas Bowen http://mrtheplague.net/toasterkit/

Toasterkit - A NetBSD Rootkit. Anthony Martinez Thomas Bowen http://mrtheplague.net/toasterkit/ Toasterkit - A NetBSD Rootkit Anthony Martinez Thomas Bowen http://mrtheplague.net/toasterkit/ Toasterkit - A NetBSD Rootkit 1. Who we are 2. What is NetBSD? Why NetBSD? 3. Rootkits on NetBSD 4. Architectural

More information

Chapter 6, The Operating System Machine Level

Chapter 6, The Operating System Machine Level Chapter 6, The Operating System Machine Level 6.1 Virtual Memory 6.2 Virtual I/O Instructions 6.3 Virtual Instructions For Parallel Processing 6.4 Example Operating Systems 6.5 Summary Virtual Memory General

More information

Priority Based Implementation in Pintos

Priority Based Implementation in Pintos Priority Based Implementation in Pintos Deepa D 1, Nivas K S 2, Preethi V 3 1, 2, 3 Students M-Tech, Dept. of Information Technology, SNS College of Engg., Coimbatore. Abstract Pintos is a simple operating

More information

C++ INTERVIEW QUESTIONS

C++ INTERVIEW QUESTIONS C++ INTERVIEW QUESTIONS http://www.tutorialspoint.com/cplusplus/cpp_interview_questions.htm Copyright tutorialspoint.com Dear readers, these C++ Interview Questions have been designed specially to get

More information

Embedded Programming in C/C++: Lesson-1: Programming Elements and Programming in C

Embedded Programming in C/C++: Lesson-1: Programming Elements and Programming in C Embedded Programming in C/C++: Lesson-1: Programming Elements and Programming in C 1 An essential part of any embedded system design Programming 2 Programming in Assembly or HLL Processor and memory-sensitive

More information

Virtual Servers. Virtual machines. Virtualization. Design of IBM s VM. Virtual machine systems can give everyone the OS (and hardware) that they want.

Virtual Servers. Virtual machines. Virtualization. Design of IBM s VM. Virtual machine systems can give everyone the OS (and hardware) that they want. Virtual machines Virtual machine systems can give everyone the OS (and hardware) that they want. IBM s VM provided an exact copy of the hardware to the user. Virtual Servers Virtual machines are very widespread.

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Traditional Rootkits Lrk4 & KNARK

Traditional Rootkits Lrk4 & KNARK Traditional Rootkits Lrk4 & KNARK Based on a paper by John Levine & Julian Grizzard http://users.ece.gatech.edu/~owen/research/conference%20publications/rookit_southeastcon2003.pdf ECE 4883 Internetwork

More information

CANnes PC CAN Interface Manual

CANnes PC CAN Interface Manual CANnes PC CAN Interface Manual Version: 1.21 October 1 st, 2004 D 20375 Hamburg, Germany Phone +49-40-51 48 06 0 FAX: +49-40-51 48 06 60 2 CANnes Card Manual V1.21 Version Version Date Author Comment 1.00

More information

Sources: On the Web: Slides will be available on:

Sources: On the Web: Slides will be available on: C programming Introduction The basics of algorithms Structure of a C code, compilation step Constant, variable type, variable scope Expression and operators: assignment, arithmetic operators, comparison,

More information

File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x

File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x Suvrojit Das +91-9734294105 suvrojit.das@gmail.com Arijit Chattopadhayay +91-9474910685

More information

8 Tutorial: Using ASN.1

8 Tutorial: Using ASN.1 8 Tutorial: Using ASN.1 Data Types This tutorial describes how to use ASN.1 types and values in the SDL suite. You will learn how to import and use ASN.1 modules in your SDL diagrams, how to generate code

More information

umps software development

umps software development Laboratorio di Sistemi Operativi Anno Accademico 2006-2007 Software Development with umps Part 2 Mauro Morsiani Software development with umps architecture: Assembly language development is cumbersome:

More information

Laboratorio di Sistemi Operativi Anno Accademico 2009-2010

Laboratorio di Sistemi Operativi Anno Accademico 2009-2010 Laboratorio di Sistemi Operativi Anno Accademico 2009-2010 Software Development with umps Part 2 Mauro Morsiani Copyright Permission is granted to copy, distribute and/or modify this document under the

More information

Freescale Semiconductor, I

Freescale Semiconductor, I nc. Application Note 6/2002 8-Bit Software Development Kit By Jiri Ryba Introduction 8-Bit SDK Overview This application note describes the features and advantages of the 8-bit SDK (software development

More information

Understanding Valgrind memory leak reports

Understanding Valgrind memory leak reports Understanding Valgrind memory leak reports Aleksander Morgado aleksander@es.gnu.org Thanks to the development team of Azetti Networks not only for supplying so many example memory leaks, but also for their

More information

Fast Arithmetic Coding (FastAC) Implementations

Fast Arithmetic Coding (FastAC) Implementations Fast Arithmetic Coding (FastAC) Implementations Amir Said 1 Introduction This document describes our fast implementations of arithmetic coding, which achieve optimal compression and higher throughput by

More information

Safety measures in Linux

Safety measures in Linux S a f e t y m e a s u r e s i n L i n u x Safety measures in Linux Krzysztof Lichota lichota@mimuw.edu.pl A g e n d a Standard Unix security measures: permissions, capabilities, ACLs, chroot Linux kernel

More information

strsep exercises Introduction C strings Arrays of char

strsep exercises Introduction C strings Arrays of char strsep exercises Introduction The standard library function strsep enables a C programmer to parse or decompose a string into substrings, each terminated by a specified character. The goals of this document

More information

EMC RepliStor for Microsoft Windows ERROR MESSAGE AND CODE GUIDE P/N 300-002-826 REV A02

EMC RepliStor for Microsoft Windows ERROR MESSAGE AND CODE GUIDE P/N 300-002-826 REV A02 EMC RepliStor for Microsoft Windows ERROR MESSAGE AND CODE GUIDE P/N 300-002-826 REV A02 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 www.emc.com Copyright 2003-2005

More information

Device Management Functions

Device Management Functions REAL TIME OPERATING SYSTEMS Lesson-6: Device Management Functions 1 1. Device manager functions 2 Device Driver ISRs Number of device driver ISRs in a system, Each device or device function having s a

More information

NDK: NOVELL NSS AUDIT

NDK: NOVELL NSS AUDIT www.novell.com/documentation NDK: NOVELL NSS AUDIT Developer Kit August 2015 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation,

More information

Setting up PostgreSQL

Setting up PostgreSQL Setting up PostgreSQL 1 Introduction to PostgreSQL PostgreSQL is an object-relational database management system based on POSTGRES, which was developed at the University of California at Berkeley. PostgreSQL

More information

Virtuozzo Virtualization SDK

Virtuozzo Virtualization SDK Virtuozzo Virtualization SDK Programmer's Guide February 18, 2016 Copyright 1999-2016 Parallels IP Holdings GmbH and its affiliates. All rights reserved. Parallels IP Holdings GmbH Vordergasse 59 8200

More information

Professional. SlickEdif. John Hurst IC..T...L. i 1 8 О 7» \ WILEY \ Wiley Publishing, Inc.

Professional. SlickEdif. John Hurst IC..T...L. i 1 8 О 7» \ WILEY \ Wiley Publishing, Inc. Professional SlickEdif John Hurst IC..T...L i 1 8 О 7» \ WILEY \! 2 0 0 7 " > Wiley Publishing, Inc. Acknowledgments Introduction xiii xxv Part I: Getting Started with SiickEdit Chapter 1: Introducing

More information

APPLICATION PROGRAMMING INTERFACE

APPLICATION PROGRAMMING INTERFACE APPLICATION PROGRAMMING INTERFACE Advanced Card Systems Ltd. Website: www.acs.com.hk Email: info@acs.com.hk Table of Contents 1.0. Introduction... 4 2.0.... 5 2.1. Overview... 5 2.2. Communication Speed...

More information

Moving from CS 61A Scheme to CS 61B Java

Moving from CS 61A Scheme to CS 61B Java Moving from CS 61A Scheme to CS 61B Java Introduction Java is an object-oriented language. This document describes some of the differences between object-oriented programming in Scheme (which we hope you

More information

IBM SDK, Java Technology Edition Version 1. IBM JVM messages IBM

IBM SDK, Java Technology Edition Version 1. IBM JVM messages IBM IBM SDK, Java Technology Edition Version 1 IBM JVM messages IBM IBM SDK, Java Technology Edition Version 1 IBM JVM messages IBM Note Before you use this information and the product it supports, read the

More information

Libmonitor: A Tool for First-Party Monitoring

Libmonitor: A Tool for First-Party Monitoring Libmonitor: A Tool for First-Party Monitoring Mark W. Krentel Dept. of Computer Science Rice University 6100 Main St., Houston, TX 77005 krentel@rice.edu ABSTRACT Libmonitor is a library that provides

More information

Jonathan Worthington Scarborough Linux User Group

Jonathan Worthington Scarborough Linux User Group Jonathan Worthington Scarborough Linux User Group Introduction What does a Virtual Machine do? Hides away the details of the hardware platform and operating system. Defines a common set of instructions.

More information

LSN 10 Linux Overview

LSN 10 Linux Overview LSN 10 Linux Overview ECT362 Operating Systems Department of Engineering Technology LSN 10 Linux Overview Linux Contemporary open source implementation of UNIX available for free on the Internet Introduced

More information

Intel P6 Systemprogrammering 2007 Föreläsning 5 P6/Linux Memory System

Intel P6 Systemprogrammering 2007 Föreläsning 5 P6/Linux Memory System Intel P6 Systemprogrammering 07 Föreläsning 5 P6/Linux ory System Topics P6 address translation Linux memory management Linux page fault handling memory mapping Internal Designation for Successor to Pentium

More information

Applying Clang Static Analyzer to Linux Kernel

Applying Clang Static Analyzer to Linux Kernel Applying Clang Static Analyzer to Linux Kernel 2012/6/7 FUJITSU COMPUTER TECHNOLOGIES LIMITED Hiroo MATSUMOTO 管 理 番 号 1154ka1 Copyright 2012 FUJITSU COMPUTER TECHNOLOGIES LIMITED Abstract Now there are

More information

Lecture 22: C Programming 4 Embedded Systems

Lecture 22: C Programming 4 Embedded Systems Lecture 22: C Programming 4 Embedded Systems Today s Goals Basic C programming process Variables and constants in C Pointers to access addresses Using a High Level Language High-level languages More human

More information

Linux/UNIX System Programming. POSIX Shared Memory. Michael Kerrisk, man7.org c 2015. February 2015

Linux/UNIX System Programming. POSIX Shared Memory. Michael Kerrisk, man7.org c 2015. February 2015 Linux/UNIX System Programming POSIX Shared Memory Michael Kerrisk, man7.org c 2015 February 2015 Outline 22 POSIX Shared Memory 22-1 22.1 Overview 22-3 22.2 Creating and opening shared memory objects 22-10

More information

Kernel Modules and Device Drivers

Kernel Modules and Device Drivers C H A P T E R 7 Kernel Modules and Device Drivers "If you think I m a bad driver, you should see me putt." Snoopy For me, the fun part of embedded programming is seeing the computer interact with its physical

More information

Object Oriented Software Design II

Object Oriented Software Design II Object Oriented Software Design II Introduction to C++ Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa February 20, 2012 G. Lipari (Scuola Superiore Sant Anna) C++ Intro February

More information

Operating System Components

Operating System Components Lecture Overview Operating system software introduction OS components OS services OS structure Operating Systems - April 24, 2001 Operating System Components Process management Memory management Secondary

More information

Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture

Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture Last Class: OS and Computer Architecture System bus Network card CPU, memory, I/O devices, network card, system bus Lecture 3, page 1 Last Class: OS and Computer Architecture OS Service Protection Interrupts

More information

Sophos Anti-Virus for Linux user manual

Sophos Anti-Virus for Linux user manual Sophos Anti-Virus for Linux user manual Product version: 7 Document date: January 2011 Contents 1 About this manual...3 2 About Sophos Anti-Virus for Linux...4 3 On-access scanning...7 4 On-demand scanning...10

More information

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives Introduction to Programming and Algorithms Module 1 CS 146 Sam Houston State University Dr. Tim McGuire Module Objectives To understand: the necessity of programming, differences between hardware and software,

More information

TELE 301 Lecture 7: Linux/Unix file

TELE 301 Lecture 7: Linux/Unix file Overview Last Lecture Scripting This Lecture Linux/Unix file system Next Lecture System installation Sources Installation and Getting Started Guide Linux System Administrators Guide Chapter 6 in Principles

More information

Java CPD (I) Frans Coenen Department of Computer Science

Java CPD (I) Frans Coenen Department of Computer Science Java CPD (I) Frans Coenen Department of Computer Science Content Session 1, 12:45-14:30 (First Java Programme, Inheritance, Arithmetic) Session 2, 14:45-16:45 (Input and Programme Constructs) Materials

More information

Configuring CoreNet Platform Cache (CPC) as SRAM For Use by Linux Applications

Configuring CoreNet Platform Cache (CPC) as SRAM For Use by Linux Applications Freescale Semiconductor Document Number:AN4749 Application Note Rev 0, 07/2013 Configuring CoreNet Platform Cache (CPC) as SRAM For Use by Linux Applications 1 Introduction This document provides, with

More information

APCI-8001, APCI-8008 and CPCI-8004

APCI-8001, APCI-8008 and CPCI-8004 POSITIONING AND CONTOURING CONTROL SYSTEM APCI-8001, APCI-8008 and CPCI-8004 ELCAM Interface Rev. 9/022014 www.addi-data.com CONTENTS 3 1 Introduction...4 2 Using the ELCAM functionality...5 2.1 Initialising

More information

1 The Java Virtual Machine

1 The Java Virtual Machine 1 The Java Virtual Machine About the Spec Format This document describes the Java virtual machine and the instruction set. In this introduction, each component of the machine is briefly described. This

More information

Install Java Development Kit (JDK) 1.8 http://www.oracle.com/technetwork/java/javase/downloads/index.html

Install Java Development Kit (JDK) 1.8 http://www.oracle.com/technetwork/java/javase/downloads/index.html CS 259: Data Structures with Java Hello World with the IntelliJ IDE Instructor: Joel Castellanos e-mail: joel.unm.edu Web: http://cs.unm.edu/~joel/ Office: Farris Engineering Center 319 8/19/2015 Install

More information

1 External Model Access

1 External Model Access 1 External Model Access Function List The EMA package contains the following functions. Ema_Init() on page MFA-1-110 Ema_Model_Attr_Add() on page MFA-1-114 Ema_Model_Attr_Get() on page MFA-1-115 Ema_Model_Attr_Nth()

More information

Operating System Monitor Application (OS MON)

Operating System Monitor Application (OS MON) Operating System Monitor Application (OS MON) version 1.3 Joe Armstrong 1997-05-02 Typeset in L A TEX from SGML source using the DOCBUILDER 3.0 Document System. Contents 1 OS MON Reference Manual 1 1.1

More information

TEL2821/IS2150: INTRODUCTION TO SECURITY Lab: Operating Systems and Access Control

TEL2821/IS2150: INTRODUCTION TO SECURITY Lab: Operating Systems and Access Control TEL2821/IS2150: INTRODUCTION TO SECURITY Lab: Operating Systems and Access Control Version 3.4, Last Edited 9/10/2011 Students Name: Date of Experiment: Read the following guidelines before working in

More information

Leak Check Version 2.1 for Linux TM

Leak Check Version 2.1 for Linux TM Leak Check Version 2.1 for Linux TM User s Guide Including Leak Analyzer For x86 Servers Document Number DLC20-L-021-1 Copyright 2003-2009 Dynamic Memory Solutions LLC www.dynamic-memory.com Notices Information

More information