Integrity-178B: Safety Critical Real-Time OS
ghs.com
ghs.com
You can see the Security Target specification and how it conforms here: https://www.commoncriteriaportal.org/files/epfiles/st_vid103...
You can see the certification report here: https://www.commoncriteriaportal.org/files/epfiles/st_vid103...
Of note in the certification requirements are:
"For example, SKPP separation mechanisms, when integrated within a high assurance security architecture, are appropriate to support critical security policies for the Department of Defense (DoD), Intelligence Community, the Department of Homeland Security, Federal Aviation Administration, and industrial sectors such as finance and manufacturing."
AVA_VLA_EXP.4 Highly Resistant on page 116:
"The NSA evaluator shall perform an independent vulnerability analysis."
"The NSA evaluator shall perform independent penetration testing."
"The NSA evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential."
First party NSA penetration test and analysis certifying it is appropriate for critical DoD systems. Note that the system is used on the F-35.
ADV_FSP_EXP.4 Formal Functional Specification on page 92:
"The developer shall provide a formal presentation of the functional specification of the TSF." Formal specification of the code.
"The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements." Formal specification matches the requirements.
ADV_IMP_EXP.3 Structured Implementation of the TSF on page 93:
"The developer shall make available, the implementation representation for the entire TSF." Full source code provided to evaluator.
"The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions." Source -> Binary translation is verified.
SKPP requires non-interference but not actual correctness, whereas with seL4 it actually is shown that a kernel call meet some formal requirement.
I've seen PikeOS, LyncSecure and VxWorks also. There's an interesting related book Embedded Systems Security and... I suppose I should investigate Ada etc.
The CEO has tons of tweets along the lines of (not really exaggerating) "my OS is perfect and cannot be hacked. I have XYZ certification. I used to work on nukes."
These are not the words I expect from someone who has actually written a meaningfully "unhackable" OS. I expect discussion of e.g. theorem proving strategies, logic systems, etc., not NIST ABC-123 certs.
In terms of usage, it felt like it was in between an RTOS like FreeRTOS, embossed, or Zephyr, and Linux. It used a lot of best practices like statically allocating memory for basically everything, so you knew you had sufficient memory (at least for anything the OS needed) when your application was loaded.
I assume it’s more about the problem domain.
I’ve met engineers with a similar attitude and they were the worst people to work with. But then again, his accomplishments are incredible. So: I’m confused.
Realize that in aerospace etc. this is possible where 9-12 9s of reliability are the common minimum accepted. Communicating this to a field which strives towards 5 9s and is used to charlatans is difficult, and he isn't succeeding. His chosen expressions sound bombastic and conversation ("can't be hacked") compared to the technical equivalents, but developers and engineers outside of this subfield wouldn't fully understand them.
> I can make any program run much faster, often 4x
does sound baffling but when backed up by his laurels, we can charitably imagine what he really means - and it's not so difficult either. From the bottom of the barrel, using slightly better algos in python to rewriting it in rust, we can all do this. His company presumably goes further with Ada, formal methods and exotic tooling to get extra performance out of microcontrolers.
if you need to certify one million lines of OS and a 1/2 million lines of your application, it's handy to have that first bit done for you. Until you find that you have a 1/2 million lines of code that interface with the OS.
so we're _done_ with this crap. say we have a 1/2 million lines of our application and 50,000 lines to talk to our hardware, and less than 10,000 for a simple executive. I don't need your scheduler (which doesn't work right), your compilers (which are just buggy old out-of-date ports) or your IDE which is just buggy, old, out-of-date eclipse with a plugin and branding. And I don't need your DO-178 artifacts for a million lines of buggy OS code when I can replace it with less code than that it takes to interface with your bug riddled OS.
And when you buy the DO-178 version, don't think it means "has less bugs". DO-178 means that it has specific artifacts including MCDC coverage against requirement based tests. All of that is very expensive. None of that means it works right. If you put your money into checklists and process, guess how much is left for "making it work right".
Garbage. If you are responsible for safety-critical software, then you are responsible for safety-critical software. Paying a 3rd party for part of the responsibility would be nice if they took any responsibility, which they don't.
So, in conclusion: Pbththththh!!! on the snake oil vendors of safety magic.
You also assert technical specifications that bear no resemblance to normal reality in the field such as 1 million lines of OS (you are generally off by a factor of 10 to 100 depending on vendor) or 1/2 million lines to interface (again, off by a factor of 10 to 100). Maybe such a thing might happen when working with a second rate vendor who does not have any real proven history or actual in-house expertise at making high criticality systems selling you a bill of goods about "certifiability"?
As far as the "semblance to reality", no that is real. Interfacing to a complex product is complicated. It's simpler to just get rid of driver models and layers and just avoid the entire thing. If you are DAL-A, then why not just be a foreground-background task and skip the "value added" OS layer. It's more reliable, and it's orders of magnitude simpler.
And at the end of the day, the integrator is responsible for all of it anyway. So i'd rather be responsible for 1-2 orders of magnitude less code than some unresponsive 3rd party and their crappy RTOS. And make no mistake - both vxWorks and "Integrity" are not just unresponsive, but absolute garbage. They exist because of ONLY checkbox compliance bureaucracies. You can quote all the "9's" you want - those nines were bought and paid for by the integrator, not the RTOS vendor.
Take the F-35 for example. It's one, and not the only one, that has eschewed COTS RTOS middleware.
For that matter, I have not used the vxWorks system, but I have used the Integrity system and literally every one of your technical characterization generalizations (1 million lines of OS, compiler is a out-of-date port, IDE is a Eclipse plugin) is wildly incorrect. Do you care to say the actual truth on any of those to show your actual familiarity on the topic?
Could you concretely explain how? I've never worked in this field and have just seen the typical rhetoric, which makes sense to me (e.g. when considering Ada's safety's higher than rust).
i've worked on vxworks, integrity, and qnx. if you are a licensee (which is ridiculously expensive), you typically see most or all of the code for this type of embedded os. and it's uniformly atrocious.
but, since it's proprietary, you can't review it or critique it publicly. all you can see is glossy press releases and whitepapers. i assure you, pull the curtain back, and what you find is beyond bad.
it's the exact same issue with internet-of-crap devices, which is more widely known. just slapping a "safety critical" label on a product or paying millions for certification doesn't fundamentally change anything: they will put out the cheapest thing they can get away with. things like DO-178, MISRA, etc. even formal-methods. are supposed to help, but they don't, especially with low-level code like an embedded os. the effort spent certifying means even less time and money available ensuring things like that their drivers flush/invalidate caches correctly and that they use memory barriers right. certification doesn't prove that at all.
we need to make ALL safety critical and security software open-source or at minimum source-available, even if it retains a proprietary license.
i don't think they did. they date back to the 1980s and there was a time when just about every printer and wireless router (WRT54) ran on vxworks. they didn't start out doing safety and security. but then much of that embedded space got eaten up, rightly so, by Linux.
so the companies focused more on security safety, automotive, aerospace, side of the market.
but then SoCs keep changing, ports to PPC and RISC-V, multicore. and lots and lots of new drivers for new hardware.
at the same time, compiler technology stopped being driven by proprietary vendor tools and the open source compilers and debuggers eclipsed the proprietary ones in terms of quality. so now what was once secret-sauce is just repackaging open-source.
so less and less real tech to differentiate themselves. and of course mergers and acquisitions happened to most (i believe green-hills is still founder owned)
so: - aging base software that was embedded, but not necessarily designed for safety - much less market share due to Linux - continuous need to add features to keep up with hardware and competition - original engineering teams and management long gone - result: sky-high prices, less money for engineering. it's a death spiral.
> Do the certifications automatically preclude open source software at the moment?
not at all. obviously, not any sprawling typical open-source hobby project is going to be suitable. but for example i like the FreeRTOS/OpenRTOS/SafeRTOS model, and take for example seL4 which is very interesting. and SQlite.
an RTOS, especially a safety-critical one, should be a tiny, simple, thing. 10-50KSLOC. what's making the commercial ones big and complicated are features being pushed by dying companies desperate to differentiate themselves and lock big programs into their product.
There's not a lot of competition in this space.
Also, just to be frank, if you’re using a solution like this, open source does not meet your requirements.
As for whether it meets your requirements, that's entirely dependent on context. In most cases it's a perfectly valid choice as long as you understand that you're taking on the associated maintenance and certification burden. In our case, it included stuff we had written and open sourced ourselves.
Are you perhaps talking about not being able to open source a work statically linked to proprietary libraries (with or without library source code) such as compiler libraries? The general problem with that is that such a work would be a derivative work [1]. If you are using a copyleft license that would mean you would be required to disclose the source code of all components including the source code of the library you received. If you do not have a license to distribute and relicense that library, it would be copyright infringement to disclose and relicense it under the copyleft license. You can not both statically link a proprietary source code library and release the derivative work under a copyleft license; that is inherently incompatible.
[1] https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySy...
To the point, unless you avoided linking the default proprietary compiler libraries (such as the C lib) any work you open sourced under a copyleft license and distributed would be in violation of the copyleft license as you and your downstream would be unable to legally supply the source code to those libraries. You could avoid this by explicitly linking a copyleft compatible library like glibc instead of the default proprietary libraries, but I suspect your lawyers did not want to deal with the hassle of validating conformance. Much easier to just say you can not use it on open source products.
This is a general problem when dealing with proprietary software components/libraries, just most people have little familiarity with that since the proprietary library industry largely died since developers do not want to pay for their software dependencies.
The terms don't apply solely to OSS code, but that's the most important thing restricted as far as anyone here is concerned.
Source: my dad works on the F-35 program.
Also there's a picture of the F-35(C) on their site, but I only thought to check after: https://www.ghs.com/AerospaceDefense.html
>Is your dad happy about you giving this info away?
the F35 use of this software is public data.[0], and 'Dad's Happiness' isn't relevant to an internet stranger.
>Do the state actors have all of this info anyway?
State actors most definitely know these kind of details, they're likely not very actionable without lots of effort; that's why they're public.
>Does it make you a target to get to him?
It rarely matters who is a target, secretive projects are typically composited in such a way as to reduce the liability and overall management access of singular entities and individuals -- in other words 'Dad' isn't ever a lynch-pin for the entire operation.
I don't know if he's fake, or a honey-pot; but it seems like a big waste of effort and resources if that's the case.
source: aerospace family.
might be helpful to change the title to integrity-178 since that appears to be the OS' name while DO-178B is a standard