Technical reports / Department Informatik
Year of publication
- 2015 (6) (remove)
- Interrupt Handling in Linux (2015)
- An interrupt is an event that alters the sequence of instructions executed by a processor and requires immediate attention. When the processor receives an interrupt signal, it may temporarily switch control to an inter- rupt service routine (ISR) and the suspended process (i.e., the previously running program) will be resumed as soon as the interrupt is being served. The generic term interrupt is oftentimes used synonymously for two terms, interrupts and exceptions. An exception is a synchronous event that occurs when the processor detects an error condition while executing an instruction. Such an error condition may be a devision by zero, a page fault, a protection violation, etc. An interrupt, on the other hand, is an asynchronous event that occurs at random times during execution of a pro- gram in response to a signal from hardware. A proper and timely handling of interrupts is critical to the performance, but also to the security of a computer system. In general, interrupts can be emitted by hardware as well as by software. Software interrupts (e.g., via the INT n instruction of the x86 instruction set architecture (ISA)) are means to change the execution context of a program to a more privileged interrupt context in order to enter the kernel and, in contrast to hardware interrupts, occur synchronously to the currently running program. Consequently, such instructions are gates to the privileged operating-system kernel (e.g., ring 0 on x86) and thus are used to request services from the kernel (i.e., system calls). A hardware-triggered interrupt indicates that some device requires attention of the processor, and hence implements a means of communication between devices and the operating system. Interrupts from hardware can greatly improve a system’s performance when devices send interrupts (e.g., a keystroke on a keyboard) instead of expensive polling of devices (e.g., periodically polling a keyboard for stroked keys). Furthermore, hardware-emitted interrupts by timers are used for timing and time measurement in general, but also for time sharing as ticks can be used to schedule another task. After arrival of an interrupt, the processor executes the interrupt ser- vice routine that is associated with this interrupt. The ISR is also referred to as the interrupt request (IRQ) handler. But as interrupts are disabled during execution of the IRQ handler, not all kinds of code can or should be executed in this IRQ context. For instance, if such routine goes to sleep with interrupts disabled, the system is likely to freeze. On the other hand, active waiting and blocking should be avoided since other interrupts with potentially urgent needs remain disabled and, hence, cannot be served. Furthermore, acquiring locks is likely to cause deadlocks. As a consequence, the Linux kernel offers various mechanisms and application programming interfaces (APIs) to implement interrupt handling in order to meet certain functional and non-functional requirements. This report focuses on how the Linux operating-system kernel handles interrupts on the software side and aims to give brief background infor- mation as well as implementation details. Detailed information about exceptions and exception handling in the x86 architecture can be found in the CPU manual ”Intel 64 and IA-32 Architectures Software Developer’s Manual”. Notice that the report does not aim for completeness, neither does it target to introduce the general concept of interrupts. It rather tries to provide information for developers, researchers and students, familiar with operating systems and operating-system concepts, how Linux handles interrupts on the software side.
- 14. GI/ITG KuVS Fachgespräch Sensornetze (2015)
- A Flexible, Adaptive System for Data-Stream Processing in Energy-Constrained Ad-hoc Networks (2015)
- Today's generation of sensor networks reflect several changes in system characteristics over traditional sensor networks. These changes affect three key aspects: energy as a fundamental resource, stream data processing, and the inherently dynamic structure of the overall system. In this paper we extract and present eight distinct challenges aligned to the key aspects which need to be addressed in the future. We use data of ongoing science and research projects to extract the most important challenges. These challenges need to be tackled in order to provide the basis for a flexible and adaptive system design which supports data-stream processing in energy-constrained ad-hoc networks.
- Privacy-Preserving Email Forensics (2015)
- In many digital forensic investigations, email data needs to be analyzed. However, this poses a threat to the privacy of the individual whose emails are being examined and in particular becomes a problem if the investigation clashes with privacy laws. This is commonly addressed by allowing the investigator to run keyword searches and to reveal only those emails that contain at least some of the keywords. While this could be realized with standard cryptographic techniques, further requirements are present that call for novel solutions: (i) for investigation-tactical reasons the investigator should be able to keep the search terms secret and (ii) for efficiency reasons no regular interaction should be required between the investigator and the data owner. We close this gap by introducing a novel cryptographic scheme that allows to encrypt entire email boxes before handing them over for investigation. The key feature is that the investigator can non-interactively run keyword searches on the encrypted data and decrypt those emails (and only those) for which a configurable number of matches occurred. Our implementation as a plug-in for a standard forensic framework confirms the practical applicability of the approach.
- Inner Source in Platform-Based Product Engineering (2015)
- Inner source is an approach to collaboration across intra-organizational boundaries for the creation of shared reusable assets. Prior project reports on inner source suggest improved code reuse and better knowledge sharing. Using a multiple-case case study research approach, we analyze the problems that three major software development organizations were facing in their platform-based product engineering efforts. We find that a root cause, the separation of product units as profit centers from a platform organization as a cost center, leads to delayed deliveries, increased defect rates, and redundant software components. All three organizations assume that inner source can help solve these problems. The article analyzes the expectations that these companies were having towards inner source and the problems they were experiencing or expecting in its adoption. Finally, the article presents our conclusions on how these organizations should adapt their existing engineering efforts.
- An Experiment in Wait-Free Synchronisation of Priority-Controlled Simultaneous Processes: Guarded Sections (2015)
- Wait-free synchronisation gives any process in the system strong progress guarantees, irrespective of number and behaviour of other processes simultaneously competing for shared resources (i.e., data structures and code sections). It ensures completion of any operation in a finite number of steps and, thus, provides the basis to derive bounded above or even constant executions times for non-sequential programs. This characteristic is of special meaning for time-dependent processes typical for real-time (embedded) systems. But wait-free synchronisation against the background of especially arbitrary data and code structures is no bed of roses. This paper is about organising non-sequential programs to the benefit of wait-free synchronisation. Conventional critical sections are designed as so called guarded sections. Unlike critical sections, preferential processes never block at entrance to a guarded section though only one process at a time is allowed to pass through. Competing processes are forced into bypass but, if necessary and by using futures, they can synchronise on concurrent state changes inside the respective section. In consequence of this measure, the execution model of guarded sections constrains the overlapping pattern of interacting (simultaneous) processes. Thereby, efficient wait-free synchronisation of the "guarding operations" is a gratifying by-product. First experiments on a 80-way multi-core system show that non-blocking wait-free synchronised guarded sections outperform lock-based protection schemes such as MCS-locks.