This document discusses mechanisms to improve operating system reliability by making it tolerant to certain user actions and enabling recovery of resources like files. It presents two kernel module drivers called the stringent and strategic tolerance drivers. The stringent driver protects important files by intercepting deletion actions and blocking the deletion. The strategic driver backs up important files on startup and recovers any missing files from the backup on shutdown. Evaluation shows the drivers can tolerate accidental user deletions with minimal performance overhead and improve system reliability. The drivers were implemented as character drivers on the Linux kernel.

1. IOSR Journal of Computer Engineering (IOSR-JCE)
e-ISSN: 2278-0661, p- ISSN: 2278-8727Volume 13, Issue 1 (Jul. - Aug. 2013), PP 07-11
www.iosrjournals.org
www.iosrjournals.org 7 | Page
Towards Reliable Systems with User Action Tolerance and
Recovery
Vivek Thachil1
, Dileesh E D2
1
(Computer Science and Engineering, Govt. Engineering College/ University of Calicut, India)
2
(Computer Science and Engineering, Govt. Engineering College/ University of Calicut, India)
Abstract : This paper presents mechanisms that enables operating system to be tolerant to certain user actions
and recovery of some resources such as files. Certain user actions can make the system completely unavailing
or unreliable. To remedy this situation, we introduce series of mechanisms under the name Tolerance Driver.
Tolerance driver can transparently protect system from user actions, recover the system configurations and
resources. There are two drivers for tolerance and recovery such as strategic and stringent. Stringent driver
uses strict methods of tolerance and Strategic driver uses strategic methods for tolerance and recovery. We have
created tolerance drivers on Linux distribution Ubuntu 12.04 as character drivers. We expect the tolerance
drivers can improve the reliability of the system. Lastly these mechanism was easily added as kernel module to
kernel as part of operating system.
Keywords - Action Tap, Stringent driver, Strategic driver, Tolerance driver, User Action Tolerance
I. Introduction
Reliability is one significant factor every operating system should try to improve. System failures due
to user actions such as accidental actions are common in every domain. Failures bring user frustration and loss
of various forms. Sometimes failures can result in huge business loss.
Most of the actions are related to loss of data by accidental deletion of files. User would go about
deleting some system file or important work file and lead to unstable system or loss of data. Hence mechanisms
to tolerate user actions are important to protect system and save user business. Most of the accidental file
deletions are stopped by user privilege levels. Some files are kept at higher privilege (accessible only to
administrator) and cannot be removed by non privileged users are so protected from normal users. But problem
arises when normal users are given higher privilege for performing certain privileged actions and end up
accidentally deleting the important files.
This paper presents a new mechanism called tolerance driver which can improve system reliability by
protecting a list of files the user want to protect. The driver makes the system tolerant to harmful user actions
and helps in recovering resources which are essential for system. In general tolerance driver track user actions
and on detecting actions that are harmful it take necessary steps to tolerate that action. Sometimes the driver
would let the user to continue the harmful action and take measures to recover the system before system goes
completely unrecoverable from damage created by action. We make following assumptions regarding the the
user environment:
1. Specific user actions such as file deletion goes through same interface or procedures leading to
deletion.
2. Intention of user action is not malicious, but are accidental and sometimes harmful.
We implemented the tolerance driver as two separate drivers with different methods for tolerance on Linux
based operating systems. Our results shows that tolerance driver could :
1. Tolerate user actions such as deletion of important files.
2. Recover important files which has gone undergone actual deletion from backup before system goes
partially or completely non-operational.
3. Can be easily integrated into the operating system.
4. Requires minimum overhead.
II. Related Work
SE Linux (Security Enhanced Linux)[1] is feature of Linux that provides mechanisms to support access
control polices. It has been integrated into Linux mainline since version 2.6. It can be used to control activities
privilege of user, process and daemon. But the mechanism is not made to tolerate privileged user, process or
daemon actions. Shadow driver[4] is a mechanism used to tolerate device driver failures affecting operating
system and applications dependent on it. It makes this possible by tracking driver actions in passive mode and
handling functionality of driver being shadowed in active mode.

2. Towards Reliable Systems with User Action Tolerance and Recovery
www.iosrjournals.org 8 | Page
III. Kernel Module and Tolerance Driver Design
Kernel modules are units that are used to improve or add the functionality of kernel. One such kernel
module is driver. Device drivers are used to communicate with devices attached to the system. But drivers are
also used to perform some other actions other than communicating with device which require privilege. Drivers
execute in highest privilege level and can do many privileged actions. User process communicate with driver via
device file and make the driver do the required advanced functionality.
3.1 User Actions and Kernel Calls
User actions including creating, opening, reading, writing and writing are converted to kernel system
calls which will call kernels and kernel will do the required functionality. System calls are interface to the kernel
used by programs to do any operations. Tolerance driver function by creating another interface between user
actions and kernel system call interface.
3.2 Tolerance Driver
A tolerance driver act as kernel module to provide tolerance for particular user action. In some system
most of the system resources are in the form of files. Hence it is essential to protect these files from removal or
permanent removal. The user action that is tolerated by tolerance driver is removal of system resource in the
form of files. All the user actions invoke one of the kernel interfaces. Tolerance driver functionality are split into
two drivers such as Stringent and Strategic driver. Stringent Tolerance Driver function by acting as interface
between User action and Kernel Interface of system call. While Strategic tolerance driver functionality has
nothing to do with intercepting user action and kernel interface. But it function to tolerate user action by means
of backup and recovery between startup and shutdown of the system.
3.3 Active and Passive Mode
Driver function in both active and passive mode. Both strategic and stringent driver are active on the
system startup. On startup they call a program called Link Collector to collect links of the files that user wants to
protect. The links are collected from Links file associated with link collector. Link collector communicate with
driver by means of device file and export the information regarding file links. When user actions are related to
file removal or deletion, stringent tolerance driver gets into active mode. It collects information regarding the
the file being removed such as its location, name and take necessary action. It matches these information with
the data collected from Link Collector. If match found it blocks the user action to remove the file.
Strategic driver is active only on system startup and shutdown. Strategic driver is passive on actions
related to file removal. But on system startup it gets active and creates backup of links representing the files that
user require tolerance. On shutdown the driver check the existence of files represented by links collects by Link
Collector. If match found it recovers the files from backup. Backup is location hidden from user by kernel
mechanisms. Backup will develop directory structure depending on which files are to be protected similar to
system file directory structure. This helps to backup to contain files of same name.
3.4 File Classes
Tolerance driver bring protection to system files including important user files. Files protected by
drivers are classified into two such as Type1 and Type2. Type1 files are essential for system function
throughout its working. Type2 files are essential for system to start working. Stringent driver tolerant user
actions to remove Type1 file and Strategic driver tolerate that with Type2 files. Type 2 files are allowed to be
removed during system working since they are recovered by the driver on system shutdown. Since the system
could start normally with Type2 files, they are backed up to Backup on startup.
3.5 Action Taps
Stringent driver function by inserting methods called Action Taps between User Action program and
Kernel Interface. It get activated on respective user action it represents such as file read, write or removal and
stays in passive mode otherwise. Removal Action Tap is invoked on file removal. Removal action tap invoke
the Stringent driver on file removal action. Stringent driver check the file to be removed with the Link Collector
information and take action. Fig.1 show the position of the driver and Removal action tap.

3. Towards Reliable Systems with User Action Tolerance and Recovery
www.iosrjournals.org 9 | Page
Fig.1 Position of Tolerance Driver and Action Tap
3.6 Stringent Tolerance Driver Design
Stringent driver need to collect links (representing files) on startup and so need to call user program
Link Collector. Link collector export the links to driver. Driver need to tap file removal actions by removal
action taps. And also to check the links of files to be removed and block user action to remove the file
representing the links. Fig.2 shows the functioning of Stringent driver. Fig.3 shows the lifetime of Stringent
driver in active and passive mode.
3.7 Strategic Tolerance Driver Design
Strategic driver also need collection of links by Link collector. Unlike Stringent driver it does not
require the removal action tap but need shutdown action tap which activate the driver on system shutdown. On
startup after link collection it need to backup the files representing links to backup for which it call user program
File Backup. File Backup program backup all files represented by links from their respective location in Backup
location. And on system shutdown it need to check the existence of file links and if not present recover it from
backup by invoking File Recovery user program. This allows users to have flexibility to experiment with system
files compared to stringent mechanism. Fig.4 shows the lifetime of Strategic driver in active and passive mode.
Fig.5 shows the function of Strategic driver.
Fig.2 Functioning of Stringent Driver

4. Towards Reliable Systems with User Action Tolerance and Recovery
www.iosrjournals.org 10 | Page
Fig.3 Lifetime of Stringent Driver
Fig.4 Lifetime of Strategic Driver
Fig.5 Functioning of Strategic Driver

5. Towards Reliable Systems with User Action Tolerance and Recovery
www.iosrjournals.org 11 | Page
IV. Tolerance Driver Implementation
Drivers where implementation as character drivers in Linux distribution Ubuntu 12.04 with kernel
version 3.5. Link Collector program works as process in user space and gets called on system startup by driver.
Functionality of link collection was delegated to user program since it was file related tasks and takes time. And
since drivers are kernel modules and execute in kernel space, we didn't want the module to do file related
actions in kernel module since it lead to may system crashes. Link Collector communicate with drivers by
means of writing to device file associated with strategic or stringent character driver.
Removal and Shutdown action taps mechanism are implemented by patching system calls. So patch
system calls are called on respective user action. Patch code invoke the driver to do necessary action for
tolerance and recovery.
V. Evaluation
Evaluation of tolerance drivers at three aspects are done namely performance, action-tolerance and
limitation.
1. Performance. Performance overhead imposed by to tolerance drivers is almost nil in passive mode. But is
invoked by action tap for each action tapped. Since processing is done only for files to be protected,
overhead in active mode is also less. Strategic driver block the system shutdown until Type2 files are
recovered and add to overhead on the system.
2. Limitations. Tolerance drivers are to tolerate accidental user actions but not to tolerate malicious intentional
user action to damage the system. Updated Links file get exported to tolerance driver only on next system
startup.
3. Action-tolerance. System was found to be tolerant to user actions related to file removal as long as limited
kernel interface patched by action tap is used for removal.
IV. Conclusion
Tolerance to harmful actions is essential for improving system reliability. We have developed and
designed tolerance drivers which could tolerate accidental user actions which may be harmful. From our
experience we see that tolerance driver could block certain user actions and recovery resources easily. Finally
these tolerance mechanisms require no change to user programs or kernel.
References
Books:
[1] Bill McCarty, SELinux, NSA's Open Source Security Enhanced Linux (O'Reilly Media, 2004)
[2] Michael Kerrisk, The Linux Programming Interface: A Linux and UNIX System Programming Handbook (1st ed, No Starch Press,
2010).
[3] William von Hagen, Ubuntu Linux Bible (1st ed, Wiley Publishing Inc., 2007).
Journal Papers:
[4] Michael M.Swift, Muthukaruppan Annamalai, Brian N. Bershad and Henry M. Levy, Recovering Device Drivers, ACM
Transactions on Computer Systems, 24(2), 2006, 333 – 360.
Proceedings Papers:
[5] Michael M.Swift, Brian N. Bershad and Henry M. Levy, Improving the reliability of c ommodity operating systems, Proc.
ACM symposium on Operating systems principles, 19th, 2003, New York, USA, 207-222.