Functional Safety standards require that the user of the library takes responsibility for the library, even if it comes from a third party. Library code becomes part of your safety-critical target device, so it has to be verified as fit for purpose. As the application developer, only you know what that purpose is. This verification is called Library Qualification.
Libraries save a lot of time and effort, both directly and indirectly. That’s not just the time and effort it takes to implement a particular functionality. Via the API (its interface), a well-designed library provides the abstraction needed to shield you from the complexity of its implementation. It can also make your application more portable and it reduces the amount of code you have to manage, maintain and debug. Libraries may even contain higher quality code than code you write from scratch. They are typically developed, scrutinized, and debugged by multiple experts before being released.
In the context of developing security or safety-critical software, these are all important benefits. Yet we have learned from experience that you cannot assume all these qualities to be true. The abstraction layer provided by the API not only hides complexity from view, it also hides any errors.
So, what do you do?
At the very least, you need to verify that the implementation adheres to the specification of the API.
Step 1
Ascertain which parts of the library you actually use. You only need to verify those parts (a shortcut to save a lot of work).
Step 2
Determine the specification of the API. User documentation is not necessarily sufficient. A specification has to be precise about the behavior of the function, including its side-effects, and also precise about what it is not capable of doing – i.e. the limits of its operation. It must define the preconditions to function calls, and the functions’ exception behavior when things go wrong.
Step 3
Obtain a test set from an independent source, that is grounded in the requirements that follow from the specification, run it and analyze the results.
Are you there yet?
That depends on the project, its ‘Safety Integrity’ level, and other conditions. But by following the three steps above you can be much more confident that the library behaves itself.
At Solid Sands, we work hard to make sure you can safely use the C and C++ standard libraries. Read how we do it in our new Light Paper. The C library tests in the latest version of SuperTest achieve close to 100% code coverage of the musl libc implementation. If you want to find out how well your libc performs, get in touch.
Dr. Marcel Beemster, CTO
Subscribe to our monthly blog!