-
Overview
-
redpesk OS releases
-
Security updates
-
Application Framework Manager
-
Application Framework Binder
-
APIs & Services
-
Security manager
-
Trusted Boot
-
Recovery features
-
redpak
-
Minimal image
- Reduce image size
- Optimizing boot time
-
kernel fragments description
- Introduction to Linux Kernel Configuration
- 01 Disable IPC, Timers and Audit
- 02 Disable Kconfig, Scheduler and Initrd
- 03 Disable Perf, Profiling and Errata
- 04 Disable EFI, Power Management Debug and Energy Model
- 05 Disable Schedutil, CPUFreq Governors and Virtualization
- 06 Disable Kprobes and Jump Labels
- 07 Disable GCC Plugins and Function Alignment
- 08 Disable Partition Parsers
- 09 Enable Inline Spinlocks and Kernel Operations
- 10 Disable Swap, Memory Hotplug and KSM
- 11 Disable Networking IPv4, IPv6, Netfilter
- 12 Disable SCTP, VLAN, TIPC, BATMAN
- 13 Disable Wireless, Bluetooth, CAN and RFKILL
- 14 Disable PCI and Firmware
- 15 Disable GNSS and ProcEvents
- 16 Disable Block Storage NBD and AoE
- 17 Disable EEPROM and Misc Drivers
- 18 Disable Network Device Drivers
- 19 Disable PHY Drivers
- 20 Disable PPP, WLAN Coexistence, and Failover
- 21 Disable Input Devices
- 22 Disable Serial, TTY and TPM
- 23 Disable I2C, Power and Sensor Drivers
- 24 Disable MFD, Display and Media Drivers
- 25 Disable USB, Sound, RTC and VirtIO
- 26 Disable Filesystem Encodings and Compatibility
- 27 Enable Minimal Cryptographic Core with SHA3 and XTS
- 28 Disable Hardware Cryptography, Keep DRBG and Jitter Entropy
- 29 Disable Kernel Debugging Features
- 30 Disable Filesystem Verity and SecurityFS
-
Zephyr in Redpesk
-
Mender redpesk (OTA)
-
Hardware support
- Download images
- Image metrics
- Trusted Boot
- Boards - ARM64
- Boards - x86_64
- Boards - Virtual
- Miscs
redpak: an Ultra Light Weight Container for embedded applications
redpak is available in redpesk OS and integration within redpesk factory is coming soon.
Links
General presentation
redpak targets embedded and critical infrastructures:
- it maximizes resource sharing (no rootfs/sharedlib duplication)
- it is designed to be auditable. While each individual node is independent, the global coherency is provided by
dnf
/rpm
andlibsolv
at the core OS level). The redpak coherency can be statically proven at the CI level before pushing the image to the target. - it simplifies container inspection (a node is an atomic subset of a rootfs)
- it uses standard management tools (
dnf
+rpm
) - built with long term support and cybersecurity in mind.
redpak motivations
- Provide application isolation
- Restricted filesystem visibility
- Resources access/usage (API, CPU, RAM, Network, …)
- Built-in security model with MAC (Mandatory Access Control)
- Maximize resource sharing & minimize system overload
- No duplication of root-fs
- Reuse shared libraries between instances
- Restrict RAM, Disk, CPU containerization cost
- Boost container startup time
- Prevent “diplomatic suitcase” container model
- Strict enforcement on installed packages & dependencies
- Keep the system auditable
- White box container model
Everyone understands that installing a software component on millions of cars, on a submarine or in a train is very different from installing a new application on a desktop or a phone.
redpak targets embedded devices used within critical infrastructure (automotive, boat, submarine, train, civil infrastructure, medical, …). redpak does not use black box containers, on the contrary it enforces a white box model where the global coherency of the system can be proven.
While each node of a redpak family owns an atomic subset of the full rootfs tree, the global coherency of each node is statically verified. Installation/updates can be proven before installation on the embedded target by an adequate CI/Build-system such as redpesk.