Automata-Based Formal Analysis and Verification of the Real-Time Linux Kernel

Total Page:16

File Type:pdf, Size:1020Kb

Automata-Based Formal Analysis and Verification of the Real-Time Linux Kernel Universidade Federal de Santa Catarina Scuola Superiore Sant'Anna Red Hat, Inc. Ph.D. in Automation and Systems Engineering Ph.D. in Emerging Digital Technologies - Embedded and Real-Time Systems R&D Platform - Core-Kernel - Real-Time Ph.D. Candidate: Daniel Bristot de Oliveira Ph.D. Supervisors: Tommaso Cucinotta Rômulo Silva de Oliveira Automata-based Formal Analysis and Verification of the Real-Time Linux Kernel Pisa 2020 ACKNOWLEDGEMENTS In the first place, I would like to thank my friends and family for supporting me during the development of this research. In particular, I would like to thank Alessandra de Oliveira for motivating me to pursue a Ph.D. degree since I was a teenager. But also for allowing me to use her computer, which was “my” first computer. I also would like to thank Bianca Cartacci, for the unconditional support in the hardest days of these last years. I would like to thank Red Hat, Inc. for allowing me to continue my academic research in concurrency with my professional life. I would also like to thank the pro- fessionals that motivated me to remain in the academy and supported this research, including Nelson Campaner, Steven Rostedt, Juri Lelli and Arnaldo Carvalho de Mello. In special, I would like to thank Clark Williams, not only for his effort in supporting my research at Red Hat but, mainly, for his adivises and personal support. I would like to thank my Ph.D. colleagues from UFSC and Sant’Anna, in special Karila Palma Silva, Marco Pagani, Paolo Pazzaglia and Daniel Casini, all the members of the Retis Lab, and the administrave staff of the TeCIP institute at Sant’Anna and the PPGEAS at UFSC for the support in the cotutela agreement, in special for Enio Snoeijer. Finally, and most importantly, I dedicate this work to my advisors. Thanks, Pro- fessor Tommaso Cucinotta and Professor Rômulo Silva de Oliveira for supporting me and guiding me in this journey, not only as an academic but as a human as well. ABSTRACT Real-time systems are computing systems where the correct behavior does not depend only on the functional behavior, but also on the timing behavior. In the real-time schedul- ing theory, a system is an abstraction, modeled using a set of variables that describe the sole timing behavior of its components. Linux is an implementation of an operating system (OS), that nowadays supports some of the fundamental abstractions from the real-time scheduling theory. Despite all improvements of the last decade, classifying Linux as a real-time operating system (RTOS) is still a source of conflict between real- time Linux and scheduling communities. The central reasons for this conflict lie in the empirical analysis of the timing properties of Linux made by practitioners, as it is ex- pected that the properties of a real-time system derive from a mathematical description of the behavior of the system. Generally, a rigorous set of proofs is required for any con- clusion about the predictability of the runtime behavior of a real-time system. The gap between the real-time Linux and real-time theory roots in the Linux kernel complexity. The amount of effort required to understand all the constraints imposed on real-time tasks on Linux is not negligible. The challenge is then to describe such operations, using a level of abstraction that removes the complexity due to the in-kernel code. The description must use a formal format that facilitates the understanding of Linux dynam- ics for real-time researchers, without being too far from the way developers observe and improve Linux. Hence, to improve the real-time Linux runtime analysis and verification, this thesis presents a formal thread synchronization model for the PREEMPT_RT Linux kernel. This model is built upon the automata formalism, using a modular approach that enables the creation of a model based on a set of independent sub-systems and the specifications that define their synchronized behavior. The thesis also presents a viable modeling methodology, including the validation strategy and tooling that compares the model against the real execution of the system. This model is then used as the base for the creation of a runtime verification of the method for the Linux kernel. The runtime verification method uses automatic code generation from the model to facilitate the development of the monitoring system. Moreover, it uses the dynamic tracing features of Linux to enable on-the-fly verification of the system, at a low overhead. Finally, the formal modeling of the kernel behavior is used as an intermediary step, facilitating the understanding of the rules and properties that rule the timing behavior of Linux tasks. These properties are then used in the formal definition of the components and compo- sition of the main metric used by the real-time Linux developers, the scheduling latency, in the same level of abstraction used by real-time researchers. The values for these variables are then measured and analyzed by a tool proposed in this thesis. Keywords: Real-time Systems. Linux kernel. Formal methods. Automata. Runtime Verification. LIST OF FIGURES Figure 1 – Thesis approach and contributions. 18 Figure 2 – Response-time analysis abstractions in a timeline. 23 Figure 3 – ftrace output. 31 Figure 4 – Trace timeflow output example. 34 Figure 5 – Non-maskable interruption timeline. 35 Figure 6 – Maskable interruption timeline. 35 Figure 7 – Real-time thread. 36 Figure 8 – Forms of thread interference. 37 Figure 9 – Forms of thread blocking. 37 Figure 10 – System and Model. 40 Figure 11 – Example of automaton. 44 Figure 12 – Example of Petri net. 44 Figure 13 – Monolithic generator G of the washer and dryer machine. 49 Figure 14 – Monolithic specification model S of the washer and dryer machine. 50 Figure 15 – S/G of the washer and dryer machine. 50 Figure 16 – Generator: Gdoor . ............................ 50 Figure 17 – Generator: Gwash. ............................ 50 Figure 18 – Generator: Gdry .............................. 50 Figure 19 – Specification: S1.............................. 51 Figure 20 – Specification: S2.............................. 51 Figure 21 – Specification: S3.............................. 51 Figure 22 – Specification: S4.............................. 51 Figure 23 – Modular generator G of the washer and dryer machine. 51 Figure 24 – Modular specification S of the washer and dryer machine. 52 Figure 25 – Modular model S/G of the washer and dryer machine. 52 Figure 26 – Modeling approach. 67 Figure 27 – Examples of generators: G05 need resched (left) and G04 Schedul- ing context (right). 71 Figure 28 – Examples of generators: G01 sleepable and runnable. 71 Figure 29 – Sets of sequences of event. 72 Figure 30 – perf task_model report dynamic. 73 Figure 31 – perf_tool definition inside the task_model structure. 74 Figure 32 – task_model and perf_tool initialization. 74 Figure 33 – perf thread_model: Events to callback mapping. 75 Figure 34 – Handler for the irq_vectors:nmi_entry tracepoint. 75 Figure 35 – process_event: trying to run the automata. 76 Figure 36 – Example of the perf thread_model output: a thread activation. 76 Figure 37 – Kernel trace excerpt. 77 Figure 38 – S18 Scheduler call sufficient and necessary conditions. 78 Figure 39 – Missing kernel events: the output of perf thread_model. 80 Figure 40 – Missing kernel events: the output of kernel tracepoints. 80 Figure 41 – Pseudo-code of tracing recurrence. 80 Figure 42 – Trace excerpt with comments of where the IRQ context is identified in the trace. 81 Figure 43 – mutex_lock not permitted with interrupts disabled. 81 Figure 44 – S12 Events blocked in the IRQ context. 82 Figure 45 – S22 Lock while interruptible. 82 Figure 46 – Trace of mutex_lock taken in the timer interrupt handler. 82 Figure 47 – Function stack, from the timer IRQ to the mutex_lock, used in the report for the Linux kernel developers. 83 Figure 48 – Verification approach. 86 Figure 49 – Wake-up In Preemptive (WIP) Model. 86 Figure 50 – Auto-generated code from the automaton in Figure 49. 87 Figure 51 – Helper functions to get the next state. 88 Figure 52 – Sleeping While in Atomic (SWA) model. 89 Figure 53 – Example of output from the proposed verification module, as occur- ring when a problem is found. 89 Figure 54 – Phoronix Stress-NG Benchmark Results: as-is is the system without tracing nor verification; SWA is the system while verifying Sleeping While in Atomic automata in Figure 56 and with the code in Figure 50; and the trace is the system while tracing the same events used in the SWA verification. 90 Figure 55 – Need re-sched forces scheduling (NRS model). 92 Figure 56 – Latency evaluation, using the SWA model (top) and the NRS model (bottom). 93 Figure 57 – NMI generator (O1). 96 Figure 58 – IRQ disabled by software (O2). 97 Figure 59 – IRQs disabled by hardware (O3). 97 Figure 60 – Context switch generator (04). 97 Figure 61 – Context switch generator (05). 97 Figure 62 – Preempt disable (06). 97 Figure 63 – Scheduling context (07). 97 Figure 64 – Thread runnable/sleepable (08). 97 Figure 65 – Need re-schedule operation (09). 97 Figure 66 – NMI blocks all other operations (R2). 99 Figure 67 – Operations blocked in the IRQ context (R3). 99 Figure 68 – IRQ disabled by thread or IRQs (R4). 99 Figure 69 – The scheduler is called with interrupts enabled (R5). 99 Figure 70 – The scheduler is called with preemption disabled to call the scheduler (R6). 99 Figure 71 – The scheduler context does not enable the preemption (R7). 100 Figure 72 – The context switch occurs with interrupts and preempt disabled (R8). 100 Figure 73 – The context switch occurs in the scheduling context (R9). 100 Figure 74 – Wakeup and need resched requires IRQs and preemption disabled (R10 and R11). 100 Figure 75 – Disabling preemption to schedule always causes a call to the sched- uler (R12). 100 Figure 76 – Scheduling always causes context switch (R13). 100 Figure 77 – Setting need resched always causes a context switch (R14).
Recommended publications
  • Demystifying the Real-Time Linux Scheduling Latency
    Demystifying the Real-Time Linux Scheduling Latency Daniel Bristot de Oliveira Red Hat, Italy [email protected] Daniel Casini Scuola Superiore Sant’Anna, Italy [email protected] Rômulo Silva de Oliveira Universidade Federal de Santa Catarina, Brazil [email protected] Tommaso Cucinotta Scuola Superiore Sant’Anna, Italy [email protected] Abstract Linux has become a viable operating system for many real-time workloads. However, the black-box approach adopted by cyclictest, the tool used to evaluate the main real-time metric of the kernel, the scheduling latency, along with the absence of a theoretically-sound description of the in-kernel behavior, sheds some doubts about Linux meriting the real-time adjective. Aiming at clarifying the PREEMPT_RT Linux scheduling latency, this paper leverages the Thread Synchronization Model of Linux to derive a set of properties and rules defining the Linux kernel behavior from a scheduling perspective. These rules are then leveraged to derive a sound bound to the scheduling latency, considering all the sources of delays occurring in all possible sequences of synchronization events in the kernel. This paper also presents a tracing method, efficient in time and memory overheads, to observe the kernel events needed to define the variables used in the analysis. This results in an easy-to-use tool for deriving reliable scheduling latency bounds that can be used in practice. Finally, an experimental analysis compares the cyclictest and the proposed tool, showing that the proposed method can find sound bounds faster with acceptable overheads. 2012 ACM Subject Classification Computer systems organization → Real-time operating systems Keywords and phrases Real-time operating systems, Linux kernel, PREEMPT_RT, Scheduling latency Digital Object Identifier 10.4230/LIPIcs.ECRTS.2020.9 Supplementary Material ECRTS 2020 Artifact Evaluation approved artifact available at https://doi.org/10.4230/DARTS.6.1.3.
    [Show full text]
  • Context Switch in Linux – OS Course Memory Layout – General Picture
    ContextContext switchswitch inin LinuxLinux ©Gabriel Kliot, Technion 1 Context switch in Linux – OS course Memory layout – general picture Stack Stack Stack Process X user memory Process Y user memory Process Z user memory Stack Stack Stack tss->esp0 TSS of CPU i task_struct task_struct task_struct Process X kernel Process Y kernel Process Z kernel stack stack and task_struct stack and task_struct and task_struct Kernel memory ©Gabriel Kliot, Technion 2 Context switch in Linux – OS course #1 – kernel stack after any system call, before context switch prev ss User Stack esp eflags cs … User Code eip TSS … orig_eax … tss->esp0 es Schedule() function frame esp ds eax Saved on the kernel stack during ebp a transition to task_struct kernel mode by a edi jump to interrupt and by SAVE_ALL esi macro edx thread.esp0 ecx ebx ©Gabriel Kliot, Technion 3 Context switch in Linux – OS course #2 – stack of prev before switch_to macro in schedule() func prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 4 Context switch in Linux – OS course #3 – switch_to: save esi, edi, ebp on the stack of prev prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 ESI EDI EBP esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 5 Context switch in Linux – OS course #4 – switch_to: save esp in prev->thread.esp
    [Show full text]
  • Real-Time Scheduling: from Hard to Soft Real-Time Systems
    Real-Time scheduling: from hard to soft real-time systems Giuseppe Lipari Luigi Palopoli Université de Lille 1 Università di Trento [email protected] [email protected] December 8, 2015 Abstract Real-time systems are traditionally classified into hard real-time and soft real-time: in the first category we have safety critical real-time sys- tems where missing a deadline can have catastrophic consequences, whereas in the second class we find systems for which we need to optimise the Quality of service provided to the user. However, the frontier between these two classes is thinner than one may think, and many systems that were considered as hard real-time in the past should now be reconsidered under a different light. In this paper we shall first recall the fundamental notion of time- predictability and criticality, in order to understand where the real-time deadlines that we use in our theoretical models come from. We shall then introduce the model of a soft real-time system and present one popular method for scheduling hard and soft real-time tasks, the resource reserva- tion framework. Finally, we shall show how resource reservation techniques can be suc- cessfully applied to the design of classical control systems, thus adding robustness to the system and increasing resource utilisation and perfor- mance. 1 Introduction arXiv:1512.01978v1 [cs.OS] 7 Dec 2015 Real-time systems are computational systems whose correctness depends not only on the correctness of the produced results, but also on the time at which they are produced. They must interact with their external environment in a timely manner: for example, real-time systems that control physical plants (digital control systems, or the so-called cyber-physical systems) must perform their computation and produce their results at the typical timing rates of the physical environment, and within a bounded delay.
    [Show full text]
  • The Next Big OS War Is in Your Dashboard
    12/4/12 The Next Big OS War Is in Your Dashboard | Autopia | Wired.com Autopia Planes, Trains, Automobiles and the Future of Transportation Infotainment LTikwe ee1t54 297 25 Sharre 39 The Next Big OS War Is in Your Dashboard By Doug Newcomb 12.03.12 6:30 AM Follow @dougnew comb Photo: Jim Merithew/Wired Competition in automotive technology has long been about who’s got the most horsepower, the best towing capacity or the fastest acceleration. These days, though, it’s all about having the slickest infotainment systems and most-connected cars. The shift in focus from what’s under the hood to what’s behind the dashboard has brought a largely covert war to the auto industry over the operating systems that will control these gadgets. As in the smartphone biz, the battle line is between proprietary and open source software. The outcome will determine what these systems look like, how they work and how distinctive they are as automakers embrace walled gardens or open ecosystems. It would be difficult to overstate the importance of getting this right. The amount of software in the average vehicle has grown exponentially — a typical new car has about 100 million lines of code — with the advent of sophisticated, cloud-connected infotainment systems. Software has become a competitive advantage as vital to General Motors or Toyota as it is to Apple or Google. The trouble is, automotive development cycles are measured in years, while the consumer www.wired.com/autopia/2012/12/automotiv e-os-war/all/ 1/11 The Next Big OS War Is in Your Dashboard | Autopia | Wired.com electronics industry works in months.
    [Show full text]
  • What Is an Operating System III 2.1 Compnents II an Operating System
    Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers.
    [Show full text]
  • Aquosa-Adaptive Quality of Service Architecture
    SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2009; 39:1–31 Published online 1 April 2008 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spe.883 AQuoSA—adaptive quality of service architecture L. Palopoli1,T.Cucinotta2,∗,†, L. Marzario2 and G. Lipari2 1DIT, University of Trento, Italy 2ReTiS Laboratory, Scuola Superiore Sant’Anna, Via Moruzzi, 1, 56124 Pisa, Italy SUMMARY This paper presents an architecture for quality of service (QoS) control of time-sensitive applications in multi-programmed embedded systems. In such systems, tasks must receive appropriate timeliness guarantees from the operating system independently from one another; otherwise, the QoS experienced by the users may decrease. Moreover, fluctuations in time of the workloads make a static partitioning of the central processing unit (CPU) that is neither appropriate nor convenient, whereas an adaptive allocation based on an on-line monitoring of the application behaviour leads to an optimum design. By combining a resource reservation scheduler and a feedback-based mechanism, we allow applications to meet their QoS requirements with the minimum possible impact on CPU occupation. We implemented the framework in AQuoSA (Adaptive Quality of Service Architecture (AQuoSA). http://aquosa.sourceforge.net), a software architecture that runs on top of the Linux kernel. We provide extensive experimental validation of our results and offer an evaluation of the introduced overhead, which is perfectly sustainable in the class of addressed applications. Copyright © 2008 John Wiley & Sons, Ltd. Received 29 June 2007; Revised 28 January 2008; Accepted 1 February 2008 KEY WORDS: resource reservations; adaptive QoS control; soft real time; embedded systems; operating systems 1.
    [Show full text]
  • Execution Time Monitoring in Linux∗
    Execution Time Monitoring in Linux∗ Mikael Asberg,˚ Thomas Nolte Clara M. Otero Perez´ Shinpei Kato MRTC/Malardalen¨ University NXP Semiconductors/Research The University of Tokyo P.O. Box 883, SE-721 23, High Tech Campus 32 (102) 7-3-1 Hongo, Bunkyo-ku, Vaster¨ as,˚ Sweden 5656 AE Eindhoven, Holland Tokyo 113-8656, Japan [email protected] [email protected] [email protected] Abstract estimate and the current system state. For example, if only one component is active, then it can run at the maximum This paper presents an implementation of an Execution QoS using 75% of a given resource. However, if a sec- Time Monitor (ETM) which can be applied in a resource ond identical component is started, then both components management framework, such as the one proposed in the will have to adapt to a lower QoS where each of them uses Open Media Platform (OMP) [4]. OMP is a European 50% of the same resource. project which aims at creating an open, flexible and re- In media processing systems, the load is very dynamic source efficient software architecture for mobile devices and the worst case is often unknown (unpredictable) or too such as cell phones and handsets. One of its goals is to high to do worst case resource allocation (since it will im- open up the possibility for software portability and fast ply wasting resources). The initial resource estimate pro- integration of applications, in order to decrease develop- vided by the component is used to create the initial allo- ment costs.
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Linux Automotive Security “Safer and More Secure”
    Linux Automotive Security “Safer and more secure” Authors Fulup Ar Foll [email protected] José Bollo [email protected] Abstract Cars are expensive pieces of equipment, yet they represent a huge mass market. Adding Internet connectivity to previous elements generates perfect conditions for the growth of a viable business model on attacking “Connected Cars”. It is already well understood that cars will be connected and connected cars will be attacked. While it's still too early to predict with certainty how “Connected Cars” will be impacted by security flaws, making the assumption that a car should be at least as secure as a TV, a set-top-box or a smart phone should make sense to everyone. This white paper focuses on how Linux best practices security mechanisms that could be used today and within the next couple of years to make connected cars safer and more secure. Version 1.0 January 2016 Linux Automotive Security Table of contents 1.Introduction...................................................................................................3 2.Make Sure You Run the Right Code...................................................................4 2.1.Before Booting............................................................................................4 2.2.When Booting.............................................................................................5 2.3.After Booting...............................................................................................5 3.Keeping Secrets Secret...................................................................................6
    [Show full text]
  • Table of Contents
    1 Vol. 32, No. 3 April 2019 Table of Contents AGL Will Be Overtaken by Android Automotive 2 SmartDrive Has Massive Data Trove for AV Developers 6 The Company Profile: NVIDIA 8 Ludwigsburg Automotive Electronics Conference: 16 June 25-26, 2019 Momentum Is Building for a Self-Driving Safety Standard 17 Roland Berger Examines the New Mobility World 18 Roundup: 2018 Financial Results for Hyundai Mobis, 19 Lear, ZF The© Hansen2019 Paul Report Hansen onAssociates, Automotive 150 Pinehurst Electronics, Road, July/August Portsmouth, NH 2016 03801 USA www.hansenreport.comTelephone: 603-431-5859; email: [email protected] All rights reserved. Materials may not be reproduced in any form without written permission. ISSN 1046-1105 2 AGL Will Be Overtaken by Android Automotive The Linux Foundation just picked up another new member to work on its Automotive Grade Linux project, the collaborative open source effort to develop a common platform that can serve as a de facto standard for infotainment, telematics and instrument cluster applications. Volkswagen joined earlier this month. Thus far 130 members have signed onto the project; 30 members signed up in 2018. There is much to recommend AGL. The AGL Unified Code Base platform provides 70% of the starting point for a production project, including operating system, middleware and application framework. “If AGL can establish itself as a true automotive platform, suppliers will have a common set of interfaces their suppliers can write to,” said Tim VanGoethem, vice president of Advanced Mobility Solutions at Harman X, the company’s innovation taskforce. “Instead of paying people to write software on your behalf, you can take advantage of what has been done already and just license it to use in your final product.” Toyota and the Linux Foundation launched AGL in 2012 and thus far only Toyota has gone on record to say that it is committed to the platform.
    [Show full text]
  • Software Defined Vertical Industries: Transformation Through Open Source
    Software-defined vertical industries: transformation through open source How open collaboration enables user-centered innovation, achieving faster development cycles, time to market, and increased interoperability and cost savings. A Publication of The Linux Foundation | September 2020 www.linuxfoundation.org “When I say that innovation is being democratized, I mean that users of products and services-both firms and individual consumers are increasingly able to innovate for themselves. User-centered innovation processes offer great advantages over the manufacturer-centric innovation development systems that have been the mainstay of commerce for hundreds of years. Users that innovate can develop exactly what they want, rather than relying on manufacturers to act as their (often very imperfect) agents.” — Eric von Hippel, Democratizing Innovation The Linux Foundation 2 Overview What do some of the world’s largest, most regulated, Over the last 20 years, the Linux Foundation has expanded complex, centuries-old industries such as banKing, from a single project, the Linux kernel, to hundreds of telecommunications, and energy have in common with distinct project communities. The “foundation-as-a- rapid development, bleeding-edge innovative, creative service” model developed by Linux Foundation supports industries such as the motion pictures industry? communities collaborating on open source across key horizontal technology domains, such as cloud, security, They’re all dependent on open source software. blocKchain, and the web. That would be both a great answer and correct, but it However, many of these project communities align across doesn’t tell the whole story. A complete answer is these vertical industry groupings, such as automotive, motion industries not only depend on open source, but they’re pictures, finance, telecommunications, energy, and public building open source into the fabric of their R&D and health initiatives.
    [Show full text]
  • Building Embedded Linux Systems ,Roadmap.18084 Page Ii Wednesday, August 6, 2008 9:05 AM
    Building Embedded Linux Systems ,roadmap.18084 Page ii Wednesday, August 6, 2008 9:05 AM Other Linux resources from O’Reilly Related titles Designing Embedded Programming Embedded Hardware Systems Linux Device Drivers Running Linux Linux in a Nutshell Understanding the Linux Linux Network Adminis- Kernel trator’s Guide Linux Books linux.oreilly.com is a complete catalog of O’Reilly’s books on Resource Center Linux and Unix and related technologies, including sample chapters and code examples. ONLamp.com is the premier site for the open source web plat- form: Linux, Apache, MySQL, and either Perl, Python, or PHP. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today for free. main.title Page iii Monday, May 19, 2008 11:21 AM SECOND EDITION Building Embedded Linux SystemsTomcat ™ The Definitive Guide Karim Yaghmour, JonJason Masters, Brittain Gilad and Ben-Yossef, Ian F. Darwin and Philippe Gerum Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Building Embedded Linux Systems, Second Edition by Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, and Philippe Gerum Copyright © 2008 Karim Yaghmour and Jon Masters.
    [Show full text]