Dynamic Analysis of ARINC 653 RTOS with LLVM Vitaly Cheptsov Alexey Khoroshilov Ivannikov Institute for System Programming Ivannikov Institute for System Programming of the Russian Academy of Sciences; of the Russian Academy of Sciences Higher School of Economics Moscow, Russia Moscow, Russia [email protected] [email protected] Abstract—Existing standards for airborne-embedded software national and international standards for secure development systems impose a number of requirements applicable to the lifecycle, like GOST R 56939—2016 [1]. software development cycle of hard real-time operating systems Safety critical software is an entirely different domain. found in modern aircraft. The measures taken are meant to reduce the risks of undesired consequences, but have strongly Creation of systems, failure of which costs human loss, injuries varying costs. Dynamic instrumentation and static analysis are or disasters resulting in severe nature or property damage, may common practices used to automatically find software defects, only be performed under a large amount of strict precautions, from strictly non-conforming code constructions to memory commonly referred to as objectives, defined in industrial corruptions or invalid control flow. LLVM analyser and sani- standards. For aviation it is DO-178C [2]. The resulting tizer infrastructure, while regularly applied to general-purpose software, originally was not thought to be introduced to heavily product has to be certified prior to being put into service, restricted environments. In this paper we discuss the specifics and history shows that the price of timely defect detection of airborne systems with regards to dynamic instrumentation is quite different at the early stage versus the verification or and provide practical considerations to be taken into account for production stage [3]. To lower the costs, additional measures, the effective use of general-purpose instrumentation tools. We sometimes not included in particular regulatory documents, bring a complete LLVM stack support to JetOS, a prospective onboard real-time operating system currently being developed are continuously sought for and efficiently applied whenever at ISP RAS in collaboration with GosNIIAS. As an example, possible. This is especially important when certifying against we port AddressSanitizer, MemorySanitizer, and UndefinedBe- multiple standards containing objectives which not necessarily haviorSanitizer and provide the details against the caveats on all conform to each other. relevant sides: a sanitizer, a compiler, and an operating system. In addition we suggest uninvolved optimisations and enhancements In this paper we study the specifics of modern airborne to the runtimes to maximise the effects of the tools. operating systems in regards to dynamic instrumentation for Index Terms—dynamic instrumentation, real-time operating early error detection. We take a set of general-purpose error systems, ARINC 653, IMA, LLVM detection tools based on the LLVM sanitizer infrastructure, tar- geting dynamic software instrumentation and error detection, I. INTRODUCTION and bring them up in a certified airborne operating system JetOS [4]. These tools are commonly applied to general- The problem of code correctness existed since before it was purpose software development projects but were not intended arXiv:2106.01766v1 [cs.SE] 3 Jun 2021 studied in computer science. As long as programming is done to be used in restricted environments. We describe which tools by humans, there will remain a high probability of mistakes in may be applicable for testing ARINC 653 applications and the the written code, which may result in program malfunctioning operating system itself, which objectives and issues could be at some point in the future. To circumvent biological imper- focused on, and the specifics of implementing sanitizer runtime fection, a number of methods reducing the risks of making support in a hard real-time operating system. We showcase mistakes during software development, decreasing the costs for possible issues to be found and suggest actions to increase the their elimination, and, most importantly, detecting the mistakes efficiency of test results in tandem with the other tools. made as early as possible, are currently being developed. Depending on the software lifecycle and regulatory doc- II. STATE OF THE ART uments used, the set of measures taken may be comprised of: coding standards, test coverage, defensive programming, Dynamic instrumentation is a way to measure program redundancy, semiformal and formal objectives to supporting behaviour by certain parameters allowing to gather information documentation, threat model conformance testing, static anal- about program performance, contract violation, coverage, and ysis, dynamic instrumentation, fuzz-testing, regular inspection, debugging at runtime. Different kinds of instrumentation may code modelling and verification, etc. The minimal objectives require code alteration on the source level or the compiler for general-purpose software development may be defined by level. In this paper we refer to dynamic instrumentation in V. Cheptsov and A. Khoroshilov, “Dynamic Analysis of ARINC 653 RTOS with LLVM,” 2018 Ivannikov Ispras Open Conference (ISPRAS), 2018, pp. 9-15, DOI: 10.1109/ISPRAS.2018.00009. © 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. the sense of compiler passes applying modifications targeting integer overflow, incorrect execution of floating-point programming error detection. calculations, incorrect boolean type assignment, etc; While the benefits of dynamic instrumentation may be vast, • ThreadSanitizer – data race condition detection tool. Used there are not so many publicly available tools that could be for finding errors in multithreaded programs; integrated at a reasonable cost. Proprietary software, such as • Control Flow Integrity – tool implementing a number of WinDbg, Intel Inspector, UNICOM PurifyPlus, Insure++, and control flow integrity checks including the detection of several others, usually target specific platforms or userspace incorrect class and function casts and invalid virtual table instrumentation, and even if free for use come with no source usage; availability. As a result, it is either impossible or very costly to • LeakSanitizer – memory leak detection tool; adopt it to embedded projects, putting aside the safety-critical • EfficiencySanitizer – tool for detecting suboptimal lan- systems segment. The few existing opensource tools have the guage constructions and APIs; exact same problems except in-house resources are to be spent • SafeStack – tool intended to protect software from stack for the bring up. buffer overflow with no measurable performance costs; Valgrind is one of the oldest and most powerful tool suites • libFuzzer – fuzz testing tool. currently developed. It supports a large number of CPUs and These tools are being continuously ported to GCC as well, was proven to be quite effective on general-purpose operating however, the GCC support list is incomplete and suffers from systems, like Linux targets, macOS, or Android. However, backport delays. On the good side, LLVM and Clang try to using Valgrind on non-Linux and even non-POSIX targets may support a reasonable amount of GCC-supported platforms and be quite challenging. One of the ways to use Valgrind could be extensions, which allows a drop-in replacement in the majority porting the code to a simulated Linux-based environment, but of the BSPs. this results in additional costs of supporting multiple systems as well as the inability to detect bugs in the original code, III. JETOS OPERATING SYSTEM which makes the task effectively unrewarding. In addition, Valgrind seriously affects the performance of the instrumented JetOS is a cross-platform hard real-time operating system code [5]. DynamoRIO based Dr. Memory and the supple- designed to control airborne equipment in modern civil avia- mental tools are quite promising, but once again the current tion. One of the fundamental requirements in its implementa- development course is focused on expanding the functionality tion is accordance with ARINC 653 [8] parts 1 and 2. ARINC and resolving the issues in general-purpose operating systems. 653 (Avionics Application Standard Software Interface) de- PowerPC or MIPS-based CPUs are not yet even considered. scribes the implementation of APEX (APplication/EXecutive), an API that regulates space and time partitioning in safety- From this perspective the LLVM project [6] favourably critical real-time operating systems for avionics. This stan- differs from the others by consisting of reusable modules han- dard allows the hosting of multiple applications of different dling compiling, building, and instrumenting stages altogether. software levels on the same hardware in the context of an Just like GNU Compiler Collection (GCC), LLVM subprojects Integrated Modular Avionics (IMA) [9] architecture. In turn, contain all the necessary components to create a fully-fledged IMA is an airborne system architecture used in modern air- toolchain for a target Board Support Package (BSP). It has an crafts (Boeing 787, Airbus A350, etc.) replacing the outdated optimizer with