[C-safe-secure-studygroup] Criteria for freely available ISO/IEC JTC 1 standards

McCall, Gavin (G.F.) gavin.mccall at visteon.com
Thu Jan 5 14:39:34 UTC 2017


Further to my comments yesterday.

Taking https://en.wikipedia.org/wiki/Hierarchy_of_hazard_control as an example of the standard approach to hazard control, we have
1) Elimination
2) Substitution
3) Engineering controls
4) Administrative controls
5) Personal protection equipment.

By taking the approach of defining a Coding Standard that can be statically enforced, we are putting in place Engineering controls at best or Administrative controls to control the hazard.

I believe we all desire a programming language that is fit for purpose, the purpose being to implement safe and secure software based solutions.

So C is presenting some challenges with its explicitly undefined, non-explicitly undefined, unspecified, and implementation defined behaviour.

Elimination is a good approach!

Flexibility to allow mixed type, mixed signage, mixed sized expressions adds to these problems. MISRA Rules 10.x attempt to control some of these issues.

The ADA model of enums is significantly stronger than C. I can create a variable of an enum type of {red, blue, green}, and then set it to the value of 27. We could write rules to limit the use to test and assignment of enums to their defined values, plus prev() and succ().

But we still have another range of problems - arithmetic overflow.

Given 
uint8_t a, b, c;
uint16_t d;
a = getvalue();  // assign a value between 0 .. 255
b = getvalue();  // assign a value between 0 .. 255
c = a + b;
d = (uint16_t) a + b;

a plus b will overflow in 32640 of the 65536 possible combinations a and b.

So we should apply data flow analysis before c = a + b to confirm that the possible range of values assigned to a and b are such that a + b < 256u in all cases.

This starts to take us down a possible path of code annotation, in a way like Spark ADA.

So, are we considering annotation?

Gavin








> -----Original Message-----
> From: C-safe-secure-studygroup [mailto:c-safe-secure-studygroup-
> bounces at lists.trustable.io] On Behalf Of McCall, Gavin (G.F.) via C-safe-
> secure-studygroup
> Sent: 04 January 2017 10:24
> To: Paul Sherwood <paul.sherwood at codethink.co.uk>; c-safe-secure-
> studygroup at lists.trustable.io
> Subject: Re: [C-safe-secure-studygroup] Criteria for freely available ISO/IEC
> JTC 1 standards
> 
> 
> 
> > -----Original Message-----
> > From: C-safe-secure-studygroup [mailto:c-safe-secure-studygroup-
> > bounces at lists.trustable.io] On Behalf Of Paul Sherwood via
> > C-safe-secure- studygroup
> > Sent: 04 January 2017 07:52
> > To: Robert Seacord <rcseacord at gmail.com>; c-safe-secure-
> > studygroup at lists.trustable.io
> > Subject: Re: [C-safe-secure-studygroup] Criteria for freely available
> > ISO/IEC JTC 1 standards
> >
> > On 2017-01-03 19:48, Robert Seacord via C-safe-secure-studygroup wrote:
> > > So tomorrow's meeting is the inaugural meeting of the WG14
> > > Safe/Secure Coding Rules study group.
> > >
> > > The charter of the group is:
> > >
> > > 1.  To study the problem of adding coverage for safety-critical and
> > > safety/security-critical issues into the existing C Secure Coding
> > > Rules TS.
> > >
> > > 2.  To study the problem of addressing safety and security issues
> > > related to parts of the C standard not currently covered by the TS,
> > > such as concurrency.
> > >
> > > 3.  To propose updates to TS 17961 based on these studies and based
> > > on experience gained with the TS since its publication.
> > >
> > > 4.  To recommend to WG14 a course of action for the resulting
> > > document, such as creating a new edition of the TS, or making it
> > > into an International Standard.
> > >
> 
> [McCall, Gavin (G.F.)]
> 5. Should we attempt to make recommendations/changes to the base
> language standard to eliminate language issues?
> Should C2x continue to be backwards compatible with all versions of C in
> terms of undefined, unspecified and unsecure behaviour?
> 
> Is there a case that C2x should eliminate safety and security concerns, rather
> than allow then, and rely on a secondary containment process to catch
> them?
> 
> Who is C2x being defined for?
> 
> > > There may be some folks on the list who don't want to be involved in
> > > this study group, or may wish to be involved in other efforts.  If
> > > you don't want to be involved, you should probably leave the study
> > > group now.  If you want to be involved in other efforts, that is
> > > great, but we shouldn't take up study group time (beyond reasonable
> > > liaison efforts).
> >
> > I agree, Robert; your original CFP set the goals clearly.
> >
> > I know that some folks here (myself included) have overlapping
> > interests (e.g. open source standards), but they should probably be
> > considered off- topic for the study group effort. Maybe we can start
> > another list for off-topic considerations, or take them at trustable-
> software at lists.trustable.io ?
> >
> > > The base document for TS 17961 was developed by CMU, btw, and
> > > contributed to ISO/IEC.  I don't know if that will help make the
> > > argument for publishing the document for free.
> > >
> > > Making this document free is great, but IMHO, largely immaterial to
> > > our goals of improving C language safety and security.
> >
> >  From responses so far, it appears that many contributors here want to
> > keep the discussion in the open, and I think there's a benefit to that
> > in any case, even if the actual target document remains closed.
> >
> > BR
> > Paul
> >
> >
> >
> > _______________________________________________
> > 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-stud
> > ygroup
> _______________________________________________
> 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


More information about the C-safe-secure-studygroup mailing list