New generation of car combines an incredible software complexity with a full Internet connectivity. As a result cybersecurity and IDS become a “must have feature” of modern software defined vehicle. Nevertheless even if within new generation of connected cars hardware resources significantly improved; embedded software capabilities remains very different from what is possible in a data centre or cloud context. When traditional IDS tend to duplicate network traffic to run detection algorithms based on well-known attack signatures; this embedded IDS architecture proposes a very different architecture that leverage Linux kernel probes to detect unexpected behaviours. This with a minimal impact on the running system and without duplication of network traffic.
With redpesk, we provide customers the ability to cross-build an embedded, CentOS Stream-based Linux distribution in the cloud. This requires a significant infrastructure: Koji/RPM builders, Angular-based WebUI, Gitlab forge, network and RPM package dependency management, Qemu test lab management, all need to come together and be connected, in a mix of Qemu virtual machines and LXC containers. Fortunately, Ansible and Proxmox comes to the rescue to manage this complexity.
In this talk, we'll present our architecture of a self-contained CI/CD environment in the cloud, to cross-build RPM packages and Linux images. We will then dive into the specifics of using Ansible to drive Proxmox and deploy a mix of Packer-built Qemu virtual machines and LXC containers. Those provide a full Koji build system (hub and builders), an Angular frontend, Go backend, a Gitlab forge as well as network isolation/firewalling and a Qemu virtual target lab. We'll continue with lessons learned from doing these deployments for multiple customers. We will finish describing solutions we are currently working on, like Ansible AWX, to address the challenges of doing it at scale and increase automation.
This talk was presented at FOSDEM 2022 in the Infra Management Devroom
Slides: [click here]
After presenting key constraints of new cybersecurity standards UN R155/R156 regulations, the session presents how redpesk open source stack helps to address those concerns, especially with it secured-by-design architecture.
The UNECE WP.29 regulation R155 for Cyber Security Management and R156 for Software Updates have been adopted in 2021 by UNECE’s World Forum for Harmonization of Vehicle Regulations. This means that cybersecurity is now non-negotiable for accessing the market in more than 60 countries, starting in July 2022.
The open source secured-by-design stack redpesk helps to fulfill regulatory requirements by providing:
- MAC-enabled Linux distribution (SMACK/SELinux)
- secure microservices architecture
- integration with RTOS for safety
- Innovative container engine fitted for embedded
- LTS on full car life (approx. 20 years)
- SOTA support
Talk presented at FOSDEM 2022
Slides: [click here]
Video: [click here]
With the exponential grows of software complexity, to keep under control the cost and time of critical embedded application development, a continuous testing infrastructure is a must have feature.
Not only software tests should be run early and automatically each time a developer push a new code commit in the system. But furthermore, as developers typically never get enough physical board to test from, it is a key to initially run tests in a virtualized environment. Nevertheless we should keep enough real hardware in the loop to limit virtualization/reality deviation and ensure developers can transparently move tests from virtualization to the real world.
This presentation shows how virtualization may ensure early code integration to reduce development/testing cycle, while at the same time keeping track with real hardware, to ensure that application is also running correctly on final production device. Finally it gives a feedback on the different challenges Iot.bzh faced while deploying its solution of continuous tests. Then focuses on the way virtualization and real targets can be combined to offer to developers a complete and efficient CI infrastructure.
Slides: [click here]
Video: [click here]
The modern, connected, embedded Linux IoT device is facing a fundamental problem: the more connected it gets, the more cybersecurity threats it faces. Data link reliability, especially in the marine case, also makes it hard to efficiently push sensor data to the cloud.
This talk shows how to implement a reliable sensor data path from a marine IoT device running the redpesk embedded distribution to the cloud. It starts with lessons learned from real-world use cases: sending data from thousands of sensors to a cloud backend served by a choppy connection. It then dives into the IoT.bzh microservice framework, its security model (based on SMACK and SELinux) and how we coupled it with RedisTimeSeries.
Those, in addition to an OpenID Connect service, allows to securely and selectively funnel data from that target to the cloud. The talk concludes with a proposal on how this open infrastructure can be used by the community at large.
Slides: [click here]
- Testing Continuously Applications Using a Cloud Based Infrastructure Using Virtualization and Real Hardware in the Loop
- Connected ships and data flows: from the on-board sensor to the cloud
- Cross debugging on Linux : A history, current state of the art and coming improvements
- Release of redpesk Arz 1.0
- Introduction to SMACK and SELinux
- From embedded Linux boat sensors to the cloud, a data journey
- Running Zephyr and Linux on the same SoC: making both worlds live together !
- Hardware Isolation Running RTOS Concurrently with AGL on Renesas R-Car
- Data continuity, from vehicle sensors to cloud databases in the AGL ecosystem
- From Smack To SELinux
- redpesk® factory demo video
- Embedded Linux, case of AGL. Lesson at ENSTA 2019
- Current Market Conditions for Automotive Supply Implies Long Term Support
- Cloud based test infrastructure to enhance software quality assurance (SQA) in AGL application developments
- Current market condition for automotive supply implies Long Term Support
- AGL-Supervision : From AGL Supervisor to platform global data collection
- AGL-µBinder : a fast, secure and seamless option to connect AGL to small ECUs?
- Wlroots : a potential foundation for Next Generation of AGL Wayland Compositor
- L4RE hypervisor consolidating multiple AGL profiles
- Updated overview of AGL signaling
- Cybersecurity for Connected Vehicle with AGL (Automotive Grade Linux)
- Skim down AGL Application Framework to bridge AGL with hard realtime subsystems
- AGL application design
- 4A (Audio Advanced Architecture) Kickstart with AGL/FF
- Moving AGL toward production with the latest test/monitoring tools.
- From Connected Cars to Connected Boats
- Presentation of AGL
- AGL Development Tools, what's new in FF
- AGL & Real Time: Architecture Options
- Véhicule Connecté Cybersécurité et Open Source
- Projet Etudiant ENSIBS - Analyseurs Statiques de code
- Binding API version 3
- X(cross) Development System update - April 2018
- Vehicle 2 Cloud - Telematics and Data collection - April 2018
- AGL 4a and audio roadmap - April 2018
- Vehicle 2 Cloud - Signaling and Data collection - April 2018
- Industrialisation of applications build in embedded environment
- AGL Audio Advanced Architecture
- IoT.bzh and AGL presentation to ENSIBS' students
- Updated AGL Security Blueprint
- Deploy AGL OS and SDK as a Binary Packaging Distribution for Developer
- AGL integration of systemd and user management
- The AGL Swiss Knife for Quick Application Prototyping
- X(cross) Development System - make AGL app development easier
- Vehicle to Cloud: Connecting Cars to Non-Automotive Internet Services
- Low level CAN binding for AGL: a generic way to handle CAN signals
- AGL Development Kit - Features and Roadmap
- Vehicule Signaling Leveraging OpenXC
- AGL Security Framework Review
- Homescreen a New AGL Platform Service