Linux Foundation Launches ELISA, an Open Source Project For Building Safety-Critical Systems (venturebeat.com) 36
The Linux Foundation today launched Enabling Linux in Safety Applications (ELISA), an open source project comprising tools intended to help companies build and certify Linux-based systems whose failure could result in loss of human life, significant property damage, or environmental damage. From a report: In partnership with British chip designer Arm, BMW, autonomous platforms company Kuka, Linutronix, and Toyota, ELISA will work with certification and standardization bodies in "multiple industries" to establish ways Linux can form the foundation of safety-critical systems across industries.
How do you feel about that? (Score:5, Funny)
Why would you say that?
Obscure joke, lets see who gets it.
Re: (Score:3, Funny)
Is it important to you to "see who gets it"?
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:1)
Damn... (Score:2)
You beat me to the nerdy joke :-|
Re: (Score:3)
Please elucidate
Re: (Score:3)
Obscure joke, lets see who gets it.
On this forum? Probably any of us who are over 40, and a not-insignificant percentage of the younger participants as well. ;-)
Re: (Score:2)
Seems legit.
Re: (Score:2)
Why? QNX is unix-y (Score:2)
OSS is safer?
Re: (Score:2)
Formal Verification (Score:5, Interesting)
Why not start with a formally verified kernel instead of the relative chaos that is Linux kernel development?
https://en.wikipedia.org/wiki/... [wikipedia.org]
The kernel and proofs are licensed under GPLv2, and tools are BSD 2-clause.
Re: (Score:3)
Formal verification like that isn't that useful for these kinds of systems.
So you have a GPL formally verified microkernel. You need to build it into a usable system. You need an SoC that it supports, and you need to provide a lot of services to the microkernel to make it do anything useful. And if you touch any of the kernel code, it's not formally verified any more.
It's a bit like how we tried to build secure systems by writing perfect, verifiable secure code. It turned into a complete nightmare, and didn
Re: (Score:2)
So you have a GPL formally verified microkernel. You need to build it into a usable system. You need an SoC that it supports, and you need to provide a lot of services to the microkernel to make it do anything useful.
That's the whole point of L4. It's currently in use in production systems. The "usable system" bits are the libraries that are BSD 2-Clause.
The solution is the same as for secure code - defence in depth. Make sure that one failure won't literally crash the system. The kernel and OS can provide a lot of services to enable that in a way that is testable and doesn't result in every developer trying to do their own thing, which as we know is always a bad idea for crypto and the same applies to a lot of safety critical stuff.
This is also the point of L4. Strict separation of even low-level components so that if a network driver crashes it doesn't take down the rest of the OS.
My point is that there is going to be a lot of work done on the Linux side of things just verifying the kernel stays in a sane state during any of these types of random, corner-case hardware events. L4 is designed from
Re: (Score:1)
That's utter horseshit. "And if you touch any of the kernel code, it's not formally verified any more." You have a known base starting point and you know your commits. You can still verify your own code, right kiddo?
The point of standardizing is so you get a predictable result every time that isn't based on random changes you have no knowledge or control over the design of. So Kernel standardizing is a key starting point for any real system.
"I actually write life critical code for a living, BTW" - Well
Obligatory XKCD (Score:1)
Another standard... [xkcd.com] Good luck with that!
What is "safety critical"? (Score:4, Insightful)
I am not sure what this will do. To me, a "safety critical" OS like QNX, LynxOS, or INTEGRITY from Green Hills software. These are all operating systems designed from the ground up to be secure, and have defense in depth through every part of the OS, some of which even support physically unclonable functions (PUFs) on chips ensuring that there is no need for a secure enclave that can be read. All of which are also real time operating systems, which ensure that if you need to get a packet at "x" time, you will get that packet. Even Kaspersky has their own RTOS.
The problem is that people want to use the same commodity development tools in the embedded arena as they use for their web pages. This can be done, but there will be a ton of code that is possibly insecure. Developing for platforms that actually need security and reliability with a secure RTOS will take a lot more time and trouble, and today's environment of "it builds, ship it", I don't think many companies really will care to go the extra mile to actually do much about safety critical functions.
Re: (Score:3, Insightful)
As far as I know, BMW has been using QNX for quite a while, and with fairly good results. I can only guess at why they want to embrace Linux more, and my two top guesses are availability of developers, and to prevent QNX from squeezing too much blood from them by helping create a viable alternative, whether they choose to use it or not.
It would be nice if Linux was self repairing (Score:1)