[SystemSafety] C for OSs

[paul_e.bennett at topmail.co.uk]

On 08/09/2019 at 9:39 AM, "David MENTRÉ" <David.MENTRE at bentobako.org> wrote:
>
>Hello,
>
>Le 06/09/2019 à 15:34, Robert P. Schaefer a écrit :
>> The problem is a contradiction in what you want to and how to go 
>about doing it.
>>
>>  For security, you have to write OS “kernel” code that controls 
>hardware.
>>
>>  For an OS to be “good”, your kernel code has to be small and 
>fast.
>>
>>  For reasons of hardware access, you need to write assembly 
>language statements to control hardware,
>>
>>  The only small fast language that supports embedding assembly 
>by pragma is C, and C is inherently insecure.
>>
>> I’m willing to entertain the notion that I am wrong
>
>I would say you are wrong, languages like SPARK and Rust are low-
>level enough to write bare-metal level code but with enough features to 
>ensure at the same time safety and security.

As one who uses Forth for my applications, I continue to have a broad
smile. For many of my applications, it has resided on the bare-metal and
been the operating system as well as abstracting out to become the
application specific language for implementing the application
requirements. Of course, I don't deal in systems that have more than
one single purpose (mainly moving machinery).

>As usual, the problem is more social than technical: people don't 
>want
>to change their habits, because they cannot due to external 
>constraints,
>or think they cannot due to external constraints.
>
>As Olwen Morgan suggested, you can often resort to design system 
>using simple formalisms like automata or petri-nets. In that case, you 
>have option to use graphical tools like SCADE that will generate C code 
>with reasonable safety features. But again, you might have many issue to
>convince people to use SCADE.
>
>But I fully agree with quote from Tom van Vleck: simply banning C
>language would probably help a lot to improve the situation. Of 
>course,
>it will never happen.

I have always held that it is possible to build fully safe and secure systems
if you have a process that tests the specification sanity, then performs the
development under strict review with appropriate levels of testing on the way
to completion. Of course, you will want to test each and every component
in the system to ensure the requirements are met and no untoward features
emerge. If you must use C, then be sure to use a reputable compiler, and
strip down and test the libraries you deploy. Above all, ensure you have full
documentation for all of those libraries. I quite like Olwen's suggestion of
randomised generation of test cases, applied to each component in turn it
could build even more confidence in the behaviour of your system.

My final question to all though is "Why should your development process for
software differ from your development process for hardware?"

My answer is that they shouldn't.

Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************