DOCSLIB.ORG

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

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Automata-Based Formal Analysis and Verification of the Real-Time Linux UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE AUTOMAÇÃO E SISTEMAS Daniel Bristot de Oliveira Automata-based Formal Analysis and Verification of the Real-Time Linux Kernel Pisa 2020 Daniel Bristot de Oliveira Automata-based Formal Analysis and Verification of the Real-Time Linux Kernel Tese submetida ao Programa de Pós-Graduação em Engenharia de Automação e Sistemas da Univer- sidade Federal de Santa Catarina para a obtenção do tí- tulo de Doutor em Engenharia de Automação e Sis- temas. Orientador: Prof. Rômulo Silva de Oliveira, Dr. Coorientador: Prof. Tommaso Cucinotta, Dr. Pisa 2020 Ficha de identificação da obra elaborada pelo autor, através do Programa de Geração Automática da Biblioteca Universitária da UFSC. Bristot de Oliveira, Daniel Automata-based Formal Analysis and Verification of the Real-Time Linux Kernel / Daniel Bristot de Oliveira ; orientador, Rômulo Silva de Oliveira, coorientador, Tommaso Cucinotta, 2020. 144 p. Tese (doutorado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós-Graduação em Engenharia de Automação e Sistemas, Florianópolis, 2020. Inclui referências. 1. Engenharia de Automação e Sistemas. 2. Tempo Real. 3. Kernel do Linux. 4. Metodos Formais. 5. Verificação. I. Silva de Oliveira, Rômulo. II. Cucinotta, Tommaso. III. Universidade Federal de Santa Catarina. Programa de Pós Graduação em Engenharia de Automação e Sistemas. IV. Título. Daniel Bristot de Oliveira Automata-based Formal Analysis and Verification of the Real-Time Linux Kernel O presente trabalho em nível de doutorado foi avaliado e aprovado por banca examinadora composta pelos seguintes membros: Prof. Marco Di Natale, Dr. Scuola Superiore Sant’Anna Prof. Giuseppe Lipari, Dr. University of Lille Prof. Rivalino Matias Junior, Dr. Universidade Federal de Uberlândia Prof. Márcio Bastos Castro, Dr. Universidade Federal de Santa Catarina Certificamos que esta é a versão original e final do trabalho de conclusão que foi julgado adequado para obtenção do título de Doutor em Engenharia de Automação e Sistemas. Prof. Werner Kraus Junior, Dr. Coordenação do Programa de Pós-Graduação Prof. Rômulo Silva de Oliveira, Dr. Orientador Pisa, 2020. To my adivisors, Tommaso and Rômulo. 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. “Este Cargo foi a Lua e voltou.” (Unknown author.) RESUMO Sistemas de tempo real são sistemas computacionais em que o comportamento cor- reto não depende apenas do comportamento lógico, mas também do comportamento temporal. Na teoria de sistemas de tempo real, um sistema é uma abstração, mode- lada usando um conjunto de variáveis que descrevem tão somente o comportamento temporal de seus componentes. O Linux é uma implementação de um sistema opera- cional (SO), que atualmente suporta algumas das abstrações fundamentais da teoria sistemas de tempo real. Apesar de todas as melhorias da última década, classificar o Linux como um SO de tempo real ainda é uma fonte de atrito entre as comunidades de desenvolvimento do Linux e da teoria de sistemas de tempo real. O principal mo- tivo para este conflito está na análise empírica feitas pelos desenvolvedores do Linux, visto que na teoria, espera-se que as propriedades de um sistema derivem de uma descrição matemática de seu comportamento. Geralmente, um conjunto rigoroso de provas se faz necessário antes de obter qualquer conclusão sobre a previsibilidade do comportamento de tempo de execução de um sistema de tempo real. A diferença entre o Linux de tempo real e a teoria de tempo real nasce na complexidade do ker- nel do Linux. Isto se dá pelo grande esforço necessário para se entender todas as restrições impostas às tarefas de tempo real no Linux. O desafio é então descrever essas operações, usando um nível de abstração que remova a complexidade inerente ao código do kernel. Esta descrição deve utilizar-se de formato formal que facilite o entendimento da dinâmica do Linux pelos pesquisadores, sem ficar muito longe da maneira como os desenvolvedores observam e melhoram o Linux. Portanto, para mel- horar a análise e verificação do Linux de tempo real, esta tese apresenta um modelo formal de sincronização de threads para o kernel PREEMPT_RT do Linux. Esse mod- elo é construído com base na teoria de autômatos, usando uma abordagem modular que permite a criação de um modelo baseado em um conjunto de subsistemas in- dependentes e nas especificações que definem seu comportamento sincronizado. A tese também apresenta uma metodologia de modelagem, incluindo a estratégia de validação e ferramentas que comparam o modelo com a execução real do sistema. Esse modelo é usado como base para a criação de uma metodologia de verificação em tempo de execução para o kernel do Linux. O método de verificação em tempo de execução usa a geração automática de código do modelo para facilitar o desenvolvi- mento do sistema de monitoramento. Além disso, este método utiliza-se dos recursos de tracing dinâmico do Linux para permitir a verificação on-the-fly do sistema, com uma baixa sobrecarga do sistema. Por fim, a modelagem formal do comportamento do kernel é usada como uma etapa intermediária, facilitando o entendimento das regras e propriedades que regem o comportamento de temporização das tarefas do Linux. Por fim, um conjunto de especificações do modelo é utilizado como uma passo lógico na definição de um conjunto de regras e propriedades que definem o comportamento de tempo das tarefas do Linux. Essas propriedades são usadas na definição formal dos componentes e na composição da principal métrica usada pelos desenvolvedores do Linux de tempo real, a latência de escalonamento, no mesmo nível de abstração usado pelos pesquisadores de tempo real. Os valores para essas variáveis são então medidos e analisados por uma ferramenta proposta nesta tese. Palavras-chave: Tempo real. Kernel do Linux. Métodos formais. Automatos. Verifi- cação. RESUMO EXPANDIDO Sistemas de tempo real são sistemas de computacionais que a corretude não depende apenas do comportamento lógico, mas também do comportamento temporal. Em out- ras palavras, a resposta a uma solicitação está correta apenas se o resultado lógico estiver correto e produzido dentro de um tempo limite ou deadline. Caso contrário, o sistema apresentará uma falha (BUTTAZZO, 2011). Na teoria de escalonamento de tempo real um sistema é uma abstração, modelada usando um conjunto de variáveis que descrevem tão somente o comportamento tem- poral de seus componentes. Por exemplo, geralmente um sistema é composto por um conjunto de n tarefas τ = {τ1, τ2, ..., τn}. Cada tarefa é definida com um conjunto de variáveis definidas pelo modelo de tarefa do sistema. Por exemplo, no modelo de tarefa esporádico, cada tarefa τi é caracterizada por um tempo mínimo entre chegadas Pi e um tempo de execução Ci . Essas tarefas são escalonadas em um conjunto de m processadores ρ = {ρ1, ρ2, ..., ρm} e também podem compartilhar q recursos σ = {σ1, σ2, ..., σq} que requerem exclusão mútua. Nesse contexto, o principal objetivo do escalonador é atribuir, de alguma forma, o tempo dos processadores de ρ e os recursos de σ às tarefas de τ a fim de concluir todas as ativações de todas as tarefas de τ cumprindo as restrições de tempo de cada tarefa. A demonstração de que um determinado algoritmo de escalonamento cumpre esse objetivo é feita por métodos analíticos conhecidos como análise de escalonamento. Linux como um sistema operacional de tempo real O Linux é uma implementação de um sistema operacional (SO) que atualmente su- porta algumas das abstrações fundamentais da teoria de escalonamento de tempo real. No Linux, do ponto de vista do escalonador, as tarefas são as threads. O objetivo dos escalonadores é atribuir o tempo dos processadores às threads do sistema. Com o SCHED_DEADLINE (LELLI et al., 2016), o Linux suporta o modelo de tarefa es- porádico, permitindo a configuração do tempo de execução e do período, equivalentes ao Ci e Pi , de uma determinada thread. Outra tecnologia importante que habilita o Linux para sistemas de tempo real é o PREEMPT_RT. Os desenvolvedores do PRE- EMPT_RT reformularam extensivamente o kernel do Linux para reduzir as seções de código que poderiam atrasar o escalonamento da thread de mais alta prioridade, com o objetivo de transformar o Linux em um sistema operacional preemptivo, aproximando o comportamento Linux ao dos sistemas preemptivos teóricos. Essa característica permite o uso do Linux para uma ampla variedade de aplicações que requerem baixa latência na resposta a uma solicitação.
Load more

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]
  • Red Hat Enterprise Linux 7 7.1 Release Notes
    Red Hat Enterprise Linux 7 7.1 Release Notes Release Notes for Red Hat Enterprise Linux 7 Red Hat Customer Content Services Red Hat Enterprise Linux 7 7.1 Release Notes Release Notes for Red Hat Enterprise Linux 7 Red Hat Customer Content Services Legal Notice Copyright © 2015 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [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]