Secure Updates for a Memory Constrained XIP System
summary
XIP runs code directly from flash (for example QSPI flash), cutting RAM use and idle power, but flash writes block execution so updating in place breaks normal updaters. Compressed kernels and ASLR are incompatible, and writes force disabling interrupts or copying executables to RAM. Practical approaches are A/B updates with a bootloader/initramfs updater or moving the updater into a secure runtime (e.g. TrustZone updater) that runs from RAM; the latter works conceptually but lacks mature open-source implementations.
AI-written summary · about
chapters (17)
- 0:00Intro
- 0:32About me
- 1:29About this presentation
- 6:27FOSS OTA updaters
- 7:50OTA updater requirements
- 9:34OTA classification 2
- 12:43Double-copy OTA
- 13:43XIP: execute in place
- 15:18XIP advantages
- 17:14XIP obstacles
- 19:41OTA and XIP: Same goals...
- 21:14sharper underwater rocks
- 22:43Userspace OTA
- 24:35RAM disk (initrd) OTA
- 25:44Bootloader OTA
- 26:10Trustzone OTA (ARM)
- 27:35Conclusions
related talks
49mGeneric System for Safe Rootfs/Kernel Upgrades without Single-Point of Failure
16mPatchlings: Enabling A/B-Equivalent OTA Updates for Deeply Embedded...
08mSubsystem Update: Seccomp, Yama, and LoadPin
19mSubsystem Update: Linux Integrity Status Update
40mUpcoming x86 Technologies for Malicious Hypervisor Protection
43mOTA Updates in the Wild: Lessons from the Field
01h 00mCreating a Spider Goat: Security with Intel CPU Transactional Memory Support
49mBreaking Hardware-Enforced Security With Hypervisors