Jia-Ju Bai

Runtime Checking for Paired Functions in Device Drivers

Device drivers usually invoke functions to allocate resources for managing hardware devices and communicating with the kernel, and these resources should be released by functions when the work is finished. Thus allocating functions and releasing functions must be invoked in pairs. However, many developers ignore this vital rule, and some allocated resources are not released in time, which may cause resource related problems like deadlocks and memory leak. For improving the resource management of device drivers, we propose an approach named Pair Dyn to check these paired functions during runtime. When the driver runs, Pair Dyn records the runtime information of allocating functions such as key parameters and return value, and dynamically detects whether the relevant releasing functions are invoked to free allocated resources during runtime. Before the driver exits, Pair Dyn automatically attempts to invoke the related releasing functions which are lacked in runtime, in order to free the allocated resources of the operation system. We have implemented Pair Dyn with the LLVM compiler infrastructure, and make the evaluation with four real device drivers in Linux version 3.10.1. The experimental result shows that with the low extra overhead, Pair Dyn can provide effective runtime checking for allocate-release paired functions. Moreover, 9 potential bugs are found in the four drivers, which are all fixed automatically before exiting. Finally, no manual modification of the source code is needed with Pair Dyn.

Mining and checking paired functions in device drivers using characteristic fault injection

ContextDevice drivers often call specific kernel interface functions in pairs to allocate and release resources, and these functions can be called as paired functions. But due to poor documentation and carelessness, developers sometimes misuse paired functions in drivers, which causes resource-usage violations. ObjectiveMany dynamic approaches have been proposed to mine API rules and check resource usage for user-mode applications, but they are rarely applied to kernel-mode device drivers due to their designs. Meanwhile, most existing dynamic approaches lack systematic mechanisms to cover error handling code, which limits their availability and scalability. Our goal is to improve dynamic analysis to solve these problems. MethodIn this paper, we propose PairCheck, a novel approach for mining and checking paired functions in device drivers, using three techniques. Firstly, we design a characteristic fault injection framework to generate test cases, which simulates occasional errors and covers most error handling code with little effort. Secondly, complete runtime information is recorded through call interception during test-case execution. Thirdly, we mine and check paired functions based on collected runtime information, name patterns and statistical analysis. ResultTo validate the availability of PairCheck, we evaluate it on 11 Linux Ethernet card drivers. PairCheck mines 37 and 43 real paired functions in Linux 3.1.1 and 3.17.2, respectively. With these mined paired functions, it finds 10 violations in Linux 3.1.1 which have been fixed in 3.17.2, and 35 new violations in 3.17.2. The replies from developers indicate the false positive rate is low. Compared to normal execution, code coverage increases by 8.3% on average. ConclusionOur work shows that it is possible to precisely mine API rules of resource usage by using characteristic fault injection. The mined rules are useful for improving the reliability of device drivers.

Automated resource release in device drivers

Device drivers require system resources to control hardware and provide fundamental services for applications. The acquired resources must be explicitly released by drivers. Otherwise, these resources will never be reclaimed by the operating system, and they are not available for other programs any more, causing hard-to-find system problems. We study on Linux driver mailing lists, and find many applied patches handle improper resource-release operations, especially in error handling paths. In order to improve current resource management and avoid resource-release omissions in device drivers, we propose a novel approach named AutoRR, which can automatically and safely release resources based on specification-mining techniques. During execution, we maintain a resource-state table by recording the runtime information of function calls. If the driver fails to release acquired resources during execution, AutoRR will report violations and call corresponding releasing functions with the recorded runtime information to release acquired resources. To fully and safely release acquired resources, a dynamic analysis of resource dependency and allocation hierarchy is also performed, which can avoid dead resources and double frees. AutoRR works in both normal execution and error handling paths for reliable resource management. We implement AutoRR with LLVM, and evaluate it on 8 Ethernet drivers in Linux 3.17.2. The evaluation shows that the overhead of AutoRR is very low, and it has successfully fixed 18 detected resource-release omission violations without side effects. Our work shows a feasible way of using specification-mining results to avoid related violations.

BP-Miner: Mining Paired Functions from the Binary Code of Drivers for Error Handling

Kernel extension functions are provided as interfaces for drivers to manage devices and resources, and there are many implicit rules about their usages. One of the most important rules is that many functions should be called in pairs. That is to say, when an error occurs in a function, the driver should call related functions to handle it and release the acquired resources before returning, and we name these functions between normal execution paths and error handling paths as paired functions. However, many developers are unaware of them, which causes lots of bugs. Therefore, it is highly significant to automatically extract paired functions and detect violations for drivers. This paper proposes an efficient tool named BP-Miner, which can extract paired functions from binary code of driver modules and detect violations for error handling in drivers with extracted paired functions. BP-Miner constructs control flow graph (CFG) based on basic blocks of binary code, and locates potential execution paths to extract paired functions. We have evaluated BP-Miner with Linux drivers 2.6.38 and 3.13.0-rc7. 76 bugs are reported by BP-Miner in 2.6.38 which have been fixed in the current latest version 3.13.0-rc7. BP-Miner spends about 90 minutes handling 3653 module files for 3.13.0-rc7, and 859 violations have been detected with 1167 extracted paired functions. As it works on the binary code, it can be utilized to check close-source drivers.

AutoPA: automatically generating active driver from original passive driver code

Original device drivers are often passive in common operating systems, and they should correctly handle synchronization when concurrently invoked by multiple external threads. However, many concurrency bugs have occurred in drivers due to incautious synchronization. To solve concurrency problems, active driver is proposed to replace original passive driver. An active driver has its own thread and does not need to handle synchronization, thus the occurrence probability of many concurrency bugs can be effectively reduced. But previous approaches of active driver have some limitations. The biggest limitation is that original passive driver code needs to be manually rewritten. In this paper, we propose a practical approach, AutoPA, to automatically generate efficient active driver from original passive driver code. AutoPA uses function analysis and code instrumentation to perform automated driver generation, and it uses an improved active driver architecture to reduce performance degradation. We have evaluated AutoPA on 20 Linux drivers. The results show that AutoPA can automatically and successfully generate usable active drivers from original driver code. And generated active drivers can work normally with or without the synchronization primitives in original driver code. To check the effect of AutoPA on driver reliability, we perform fault injection testing on the generated active drivers, and find that all injected concurrency faults are well tolerated and the drivers can work normally. And the performance of generated active drivers is not obviously degraded compared to original passive drivers.

Automated and Reliable Resource Release in Device Drivers Based on Dynamic Analysis

Abstract In a modern operating system, device drivers acquire system resources to work. The acquired resources should be explicitly released by the drivers, because the operating system never reclaims them. Moreover, improper resource release can cause system crashes or hangs. Thus resource release is very important to driver reliability. However, according to our study on Linux driver mailing lists, many applied patches involve the modifications of resource release. Thus current resource management in drivers is not reliable enough. In this paper, we propose a novel approach named AutoRR, which can automatically and reliably release resources based on dynamic analysis. To identify resource handling operations, we use the dynamic specification-mining technique to mine resource acquiring and releasing functions. During execution, we maintain a resource-state list by intercepting the mined functions. If the driver fails to release acquired resources, AutoRR will report bugs and call corresponding releasing functions to safely release the resources. Dynamic analyses of resource dependency, allocation hierarchy, error handling form and releasing time are performed to avoid introducing new bugs when releasing resources. The evaluation on 12 Linux drivers shows that 40 detected bugs are all successfully and safely tolerated, and the overhead is only 7.84%.

Complete Runtime Tracing for Device Drivers Based on LLVM

Device drivers often suffer from much more bugs than the kernel, so testing device drivers becomes more and more important and necessary. In software testing, runtime tracing is an important technique to monitor real executing procedures of the program. Meanwhile, runtime information can also assist the programmer to make more accurate analysis of the program, like verifying the correctness of code execution and detecting bugs. However, due to kernel-mode execution and high complexity of kernel code, completely tracing drivers is hard, which causes real execution paths can not be clearly identified. In order to provide more powerful support for software testing of device drivers, we propose a method named Driver Trace, to do complete runtime tracing at the function level. Driver Trace utilizes instrumentation technique for runtime tracing, which is implemented based on LLVM compiler infrastructure. When the target driver works, Driver Trace records complete runtime information of function calls, like function names, return values and parameter pointers, and the information is recorded in a log file for future analysis. We have successfully implemented Driver Trace on 10 real device drivers in Linux 3.16.4 and made the evaluation as well. The experimental results show that Driver Trace provides an effective method of runtime tracing for device drivers with the modest overhead. Moreover, using an automated analysis of the runtime information recorded by Driver Trace, we also find 6 violations about resource usages in these 10 device drivers.