Please excuse my ignorance, but can a company facing these problems adopt QNX and run what they have in Linux on top. Or, would this involve re-writing everything from scratch?
The pattern I see across major OEMs is a safety-certified RTOS such as QNX at the foundation, with a safety-certified hypervisor partitioning the system. Linux then runs as a guest for non-safety workloads rather than directly hosting safety-critical functions.
The goal isn’t to replace Linux. It’s to contain it and preserve the freedom-from-interference argument required for ASIL D. That’s why vulnerabilities like Januscape matter even after they’re patched.
Well said Sir - I believe there are going to be a lot of tears shed in future by any company that tried to save a few $$$ or allowed an employee to create their own little Linux kingdom based on safety.
Linux is incredibly valuable in the right part of the vehicle compute stack, but the danger starts when convenience slowly turns into architecture. A team begins with a practical engineering choice, then builds more and more safety-relevant assumptions on top of it, and eventually the organization has a “Linux kingdom” that is operationally useful but very difficult to defend as an ASIL D safety argument.
The real issue is not whether Linux or KVM can be patched. They can. The issue is whether the safety case depends on a large general-purpose software stack continuing to behave perfectly as the isolation boundary. That is a very different claim, and it is one assessors, regulators, and eventually plaintiffs will examine much more closely.
Please excuse my ignorance, but can a company facing these problems adopt QNX and run what they have in Linux on top. Or, would this involve re-writing everything from scratch?
I don’t think it’s an either/or choice.
The pattern I see across major OEMs is a safety-certified RTOS such as QNX at the foundation, with a safety-certified hypervisor partitioning the system. Linux then runs as a guest for non-safety workloads rather than directly hosting safety-critical functions.
The goal isn’t to replace Linux. It’s to contain it and preserve the freedom-from-interference argument required for ASIL D. That’s why vulnerabilities like Januscape matter even after they’re patched.
Thanks.
You are welcome.
Well said Sir - I believe there are going to be a lot of tears shed in future by any company that tried to save a few $$$ or allowed an employee to create their own little Linux kingdom based on safety.
Thank you. I think that is exactly the risk.
Linux is incredibly valuable in the right part of the vehicle compute stack, but the danger starts when convenience slowly turns into architecture. A team begins with a practical engineering choice, then builds more and more safety-relevant assumptions on top of it, and eventually the organization has a “Linux kingdom” that is operationally useful but very difficult to defend as an ASIL D safety argument.
The real issue is not whether Linux or KVM can be patched. They can. The issue is whether the safety case depends on a large general-purpose software stack continuing to behave perfectly as the isolation boundary. That is a very different claim, and it is one assessors, regulators, and eventually plaintiffs will examine much more closely.