RV: where are we?
summary
Runtime verification (RV) is now merged in mainline (6.0) as a tracing-based subsystem that runs automata as per-CPU C monitors generated by the tool dot2k. Monitors run online synchronous in-kernel, emit trace events, and can trigger reactors such as printk or panic. Measured overhead is lower than full tracing-for-later-analysis. Work includes a dot-to-BPF path, missing monitor option APIs, and collaboration with ELISA for safety certification evidence.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 4:20Where are we from
- 14:09Merged
- 15:13Interface
- 22:46Implementation
- 27:47Subsystem
- 27:57Watchdog
- 30:04Monitor options
- 33:16Monitors as modules
- 33:55Monitors with BPF
- 35:40Safety Critical Systems
- 36:51Conclusion
- 37:58Questions
related talks
42mRV and the deadline scheduler: how to verify your subsystem at runti...
22mFormal Runtime Error Detection During Development in the Automotive Industry
18mRISC-V Spotlight: Improving RISC-V Quality with Verification Standards and Advanc...
16mNetVRM: Virtual Register Memory for Programmable Networks
59mProposing a new tracer to monitor RT task behavior
01h 01mNetwork Verification: Past, Present, and Future
16mKRR: Efficient and Scalable Kernel Record Replay
15mTP-DejaVu: Combining Operational and Declarative Runtime Verification