
Making robust software: the “Mars Code” talk (2012) - vog
http://www.verticalsysadmin.com/making_robust_software/
======
atsaloli
Dr Holzmann's "The Power of 10: Rules for Developing Safety-Critical Code" was
published in June 2006 issue of IEEE Computer Society "Computer" magazine. It
is a small standard, easy to understand and remember; mechanically verifiable;
and measurably effective.
[http://spinroot.com/gerard/pdf/P10.pdf](http://spinroot.com/gerard/pdf/P10.pdf)

~~~
codemac
The only one odd here for me is the ban on de-referencing more than one level.

Even a simple linked list implementation uses double pointers to reset parent
nodes.. Does anyone have insight into the risk in static analysis? Seems like
it would be handled by whatever logic was handling normal pointer derefs.

Seems like the only argument is the one against function pointers, which is a
pretty amazing thing to ban but at least provides logic WRT static analysis.

------
SeanDav
> _" The color coding green/yellow/red had a psychological effect. The
> software developers worked really hard to make all the buttons go green."_

There is a possible risk element of Cargo Cult'ing here. I would hope that all
programmers understood _why_ the buttons weren't green. It sounds like they
would have, having been certified, and in an environment that lives and
breathes code safety, but it is always worth being aware that metrics like
that can have hidden consequences.

------
adrianN
I wonder how much easier it would be to write the software in a language other
than C/C++. Ada has a pretty mature toolchain for security critical software
development. Where I work we still use C++, but mostly for political reasons.
Rust also seems more suited for security critical engineering.

~~~
seanmcdirmid
At that level of reliability, language matters surprisingly little since
everything is heavily tested, reviewed, hand verified, etc... Language safety
is a cheap high-value solution, but might not make sense when coupled with
other more expensive safety solutions (imagine wearing a simple seatbelt with
a complete safety harness, they aren't additive). C/C++ have other benefits:
minimal abstraction, lots of trained up talent.

~~~
adrianN
I agree that the resulting quality doesn't really depend on language choice. I
just wonder about the development cost. For example, a lot of time can be
spent reviewing code and checking that no unsafe constructs are used. A safe
language makes that unnecessary. Some of those checks can be automated, but in
my experience there is still a lot of manual checking going on.

I think that the main advantage of C/C++ is the number of people who speak it.
But my guess is that the time to train a competent programmer in a safe
language can be easily saved in improved productivity.

~~~
notalaser
The main advantage of C (and, to a lesser, but still very significant degree,
C++) in this field -- besides the number of people who speak it -- is the
availability of a great deal of mature, well-tested compilers, static analysis
tools and so on.

We have about 40 years of experience writing C compilers today (and we still
screw it up sometimes; C++ is... well, I mean, we have about 30 years of
experience writing C++ compilers, but those are still in the "mostly right"
state). Many subtleties of the language are well understood and many problems
have had idiomatic, well-known, widely-used solutions for decades now.

Ada would be a good choice for such projects but for the relative flimsiness
of its ecosystem. It's a great language, but its development is fairly
underfunded, and back when all this stuff was happening, its future was very
uncertain (it still is, I guess).

And when I say "fairly underfunded" and with a "very uncertain" future, you
should understand that I mean "it used to be funded by the DoD, but with
various levels of commitment" and "only a few companies, most of them
government contractors, and maybe a few state institutions along with a small,
but enthusiastic community were pushing for it".

Its fame on HN and Reddit may not indicate it, but Rust fares even worse in
this regard. Ten years from now, Rust may not even exist anymore.

It's not only about technical merit. Projects like these would benefit _a lot_
from being written in Ada (and Rust, too, I guess -- it's a great language),
provided that there were such a well-developed ecosystem around either of
them. But there isn't. E.g. when choosing their static analysis tools, these
guys settled for _the top 5 solutions_. Top 5! They evaluated a bunch of
programs and settled for the best 5. I don't think there are 5 static analysis
solutions for Rust _in total_ (and I'm pretty sure there are only two or three
for Ada that have been maintained after 1999 or so).

~~~
nickpsecurity
Excellent response. My default recommendation is Ada + SPARK but I can easily
recommend a C subset + tooling for those reasons. Especially on the compiler
issue as it's known that Ada compilers aren't what they advertise themselves
to be. The static analysis observation I'm not as sure about. A combo of
SPARK, safe concurrency, the monitor concept w/ restarts or failovers, and one
analysis tool should cover about anything they want. There's a quality vs
quantity effect in Ada vs C static analysis where I can't be sure which wins
here.

The ecosystem is really weak, though. There's no doubt about that. I don't see
that changing regardless of whether Ada stays around. It's why I'm excited
about Rust's mainstream adoption where it might get where Ada is or exceed it
as tooling improves. It's one of few times mainstream goes for The Right Thing
over Worse is Better. Eiffel, esp SCOOP model, being another good example that
has significant momentum. The CompSci people are doing amazing things with
SCOOP extensions right now that could be implemented in an Ada successor.

So, still potential at least. Plus, at least our tooling for C is now good
enough to emulate Ada's safety with the right people doing the work. Plus, we
_only_ have to buy 5 tools now. Much improvement over old days. ;)

~~~
notalaser
> It's why I'm excited about Rust's mainstream adoption where it might get
> where Ada is or exceed it as tooling improves.

Me too! We had a great chance with Ada and we kindda wasted it. Rust is
literally a second chance. This is pretty rare in tech.

------
duhast
I wonder: why this publicly funded code isn't available for download on GitHub
or NASA website. Is this because Russians and Chinese can "steal" it and send
another Curiosity to Mars?

~~~
humanrebar
Not a complete answer, but certain kinds of NASA tech undoubtedly has military
applications.

[https://en.wikipedia.org/wiki/International_Traffic_in_Arms_...](https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations)

I think your question is valid nonetheless, especially for the USPS, Dept. of
Education, etc.

~~~
fatlasp
This. I work at a space research lab and we can't even let many of our
employees view mission code; let alone the public. Violating export controls
in any way could cost us our funding

------
detaro
And still:

 _The second was a software bug which led to a wrong file being deleted as
part of regular housekeeping activities. The fix was straightforward and was
applied and the MSL continues its investigation of life on Mars._ (end of the
article)

------
noselasd
There's also some similar talks/presentations on various topics related to
software development for spacecrafts from the yearly Flight Software Workshop
at APL: [http://flightsoftware.jhuapl.edu/](http://flightsoftware.jhuapl.edu/)

------
nickpsecurity
Very good read. Thanks for submitting it. I like that there's significant
overlap in the list in the summary and the list I produced of examples of
techniques for improving software quality:

[http://pastebin.com/xZ6m4T8Z](http://pastebin.com/xZ6m4T8Z)

Further validates those aspects of my list. I'll keep recommending them. Most
tools and the rule list are available but I see no link for scrub on his
website. Is it not going to be freely distributed or just not ready for public
release? More tools for code review that are field-proven is A Good Thing to
have.

~~~
atsaloli
Yay! Glad you enjoyed it.

------
Tibbes
For those interested in the "Static Source Code Analysis" section, "Semil" is
a typo for "Semmle" [1]

[1]: [https://semmle.com/customers/code-exploration-at-
nasa/](https://semmle.com/customers/code-exploration-at-nasa/)

------
oxplot
> For example, coding standard says every "switch" statement has to have a
> "default" case. grep "switch", grep "default", and you get wildly different
> numbers! Standards were not being followed.

Are they implying that MSL is the first time they used automated code checks?

------
FLUX-YOU
When you can't use recursion, what data structures/algorithms do you use in
place of the common data structures that often use recursion? I'm thinking of
stuff like trees and quicksort. Do they even need these things?

~~~
pieceof314
Loops. A recursive algorithm can be transformed into an iterative looping
algorithm that uses a fixed stack of memory.

There's probably no change in the algorithms. They just use non-recursive
versions.

~~~
marcosdumay
What's the gain? If you turn your recursive algorithm into an iterative one
with a stack, you are sill subject to all the same problems.

They probably don't use trees and quicksort at all.

~~~
ktRolster

      > What's the gain? 
    

You can prove that you won't have a stack overflow. You can calculate the
maximum depth of the stack at compile time, not runtime.

~~~
dclowd9901
Can't you also just pass a bit through the recursion that contains its depth,
and halt the recursion if that number gets too high?

~~~
ktRolster
Yes, but that depends on making sure you get the programming logic correct,
whereas with banning recursion outright, it can be tested automatically.

------
dimman
Anyone else than me (as a C programmer) that felt like: "Nice, most things
mentioned are how I prefer to do it anyway"?

------
efaref
> For example, coding standard says every "case" statement has to have a
> "default" switch. grep "case", grep "default", and you get wildly different
> numbers!

I hope that's an error in the document. I assume they meant "$(grep -r 'switch
(' . | wc -l) != $(grep -r 'default:' . | wc -l)".

~~~
noselasd
It's a summary of the talk at
[https://vimeo.com/84991949](https://vimeo.com/84991949) , where Holzmann just
mentions the use of grep verbally, not giving the exact commands to run.

