[C-safe-secure-studygroup] Fwd: [trustable-software] Open Source Deterministic Programming standard... Help Wanted

[Clive Pygott]

Just picking up some of the points made so far:

> A) we write some code and expect it to do (only) what we think it does
> B) we apply some rules (preferably plus tooling) to help us to improve
>      our confidence that our expectation A) is satisfied

Just to clarify (as someone on a MISRA working group) MISRA and I believe
CERT only aim to address half of A.  We have no idea what you think your
program does. What we can address is that there is only one valid
interpretation of your program, so whoever/whatever  looks at it will agree
what the behaviour of the program will be. Whether that is what you
intended or not is a separate question. In C terminology that means: no
undefined behaviour, no unspecified behaviour that can have a visible
impact on the behaviour of the program, and as far as possible, reduce the
impact of implementation defined behaviour (e.g. use types like int32_t
that are a fixed size, rather than int).  My analogy is that we are like
building inspectors, checking your program's foundations are up to code. We
can say you've got services coming into the property and the foundations
will stop the building collapsing, but we don't say its fit for purpose.

> Yup. But I live in hope as described above. The C-safe-secure-study group
> is out of time imo, so we need to try something new.

I may be temped to agree with you, if we are considering low risk
applications - where today scant regard may be made to safety and security,
so any improvement is worth having. My problem is that if we are working on
a standard that aims to address the full range of risk (I tend to work on
flight-critical avionic and automotive applications). There needs to be a
recognition that there are already system level standards that need to be
considered (ISO/IEC61508 and DO178C to name two). These tend to avoid
detailed requirements on software design, but do place significant
requirements on the design process - one of which 'use an appropriate
coding standard'. You need a better justification of why a standard should
be regarded as "appropriate", than 'its better than nothing'

      Clive Pygott
      LDRA Inc




On Fri, Sep 21, 2018 at 9:03 AM Paul Sherwood <paul.sherwood at codethink.co.uk>
wrote:

> I received some questions off-list, am replying on-list since I think
> the clarification is more widely relevant
>
> > Paul Sherwood <paul.sherwood at codethink.co.uk>:
> >> Date: Thu, Sep 20, 2018 at 2:30 PM
> >> Subject: [trustable-software] Open Source Deterministic Programming
> >> standard... Help Wanted
> >> To: systemsafety
> >> <systemsafety-bounces at lists.techfak.uni-bielefeld.de>,
> >> C-safe-secure-studygroup
> >> <c-safe-secure-studygroup-bounces at lists.trustable.io>
> >> Cc: <trustable-software at lists.trustable.io>
> >
> >> In the context of several of these factors an open standard set of
> >> rules
> >> to help C programmers achieve deterministic behaviour would be
> >> generally
> >> useful, but even moreso if accompanied by tests that can be run to
> >> ensure that the rules are met.
> >
> > I'm not sure what you mean by "deterministic" in this context.
>
> I'm just meaning:
>
> A) we write some code and expect it to do (only) what we think it does
> B) we apply some rules (preferably plus tooling) to help us to improve
> our confidence that our expectation A) is satisfied
>
> As I understand it some languages are expressly designed towards this
> goal (e.g. Rust, Haskell), but obviously some of the established
> languages were not. (The first and key target/candidate for me being
> 'C', because it's still used in various crucial and popular components).
>
> > If you mean "deterministic builds" (aka reproducible builds, that is,
> > rebuilds produce the same bits), look here:
> > https://reproducible-builds.org/docs/
>
> I do not mean "deterministic builds" in this discussion. The
> construction process as separate from design/creation/writing. getting
> to bit-for-bit reproducible construction is clearly important, but
> that's not the request in this discussion.
>
> > Other than that, I think you need to more clearly define your goals.
>
> My goals can move, based on what community members see as important and
> are interested in contributing to.
>
> Overall I'm aiming to generate evidence to support a "here's why we
> think it's ok to trust foo" argument. If we can come up with ways to
> increase our confidence in important/pervasive C foo, that will be a
> worthwhile achievement imo.
>
> >> While the MISRA and CERT rules are
> >> interesting in themselves and established as de-facto for their target
> >> audiences, I'm particularly interested in rules that could be brought
> >> to
> >> and applied by the open source communities upon whose work we all
> >> increasingly rely.
> >
> >> One of the criticisms of some open source projects is that they don't
> >> follow common industry standards, and changing that is obviously an
> >> uphill task.
> >
> > Unfortunately, many legacy standards processes have not adapted well
> > to the rapid adoption of open source software (OSS).
> > As I've noted before to the "C Safety & Security Study" group, if a
> > standard isn't freely available,
> > most people are going to ignore it - and that's especially true for
> > OSS projects.
>
> I totally agree (I've made similar points on the list at various times).
> Hence this help wanted ad :)
>
> > In addition, many organizations do *not* care if there's a
> > documentation standard -
> > they want to download the OSS tool & run it to do the checking, and
> > that's it.
> > OSS libraries and tools have increasingly become executable standards
> > that
> > are more directly useful than a paper document, & they can evolve more
> > rapidly too.
>
> Yup. I'm kind of ok with that, since my dream is that we could develop a
> practical set of rules that even the GCC and kernel communities might be
> happy to apply and run on all of their future CI? Can't blame me for
> trying :-)
>
> > That's not to say that standards are useless - I think standards are
> > vital -
> > but standards efforts need to work within the modern context.
> > In short: sometimes the problem isn't that OSS don't follow common
> > industry standards -
> > sometimes the problem is that OSS unhinges the historical
> > assumptions made by some standards groups.
>
> Yup. But I live in hope as described above. The C-safe-secure-studygroup
> is out of time imo, so we need to try something new.
>
> >> Putting aside for now any emphasis on 'safety' and/or 'security',
> >> would
> >> there be any merit/interest in public collaboration on a new document
> >> (with tests) focusing on deterministic behaviour of C (and maybe other
> >> languages), for general consumption?
> >
> > I think many of us would need to know what "deterministic" means in
> > this context.
>
> I hope the above has helped?
>
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
>
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20180921/838174c9/attachment-0001.html>