Document ISO/IEC/JTC 1/SC 22/WG 23 N0687

24 January 2017

Meeting Minutes Meeting #47
ISO/IEC JTC 1/SC 22/WG23
23-24 January 2017


Meeting Location :

Holiday Club Vacations at Orange Lake – North Village

8505 W. Irlo Bronson Parkway (Hwy 192)

Kissimmee, Fl


Meeting Times:

23-24 January 2017: 0900-1700 Eastern Standard Time (1400-2200 UTC

Attendees

Stephen Michell – Convenor
Erhard Ploedereder – WG 9
Larry Wagoner – WG 14
Joyce Tokar – WG 9, Editor Part 2
Clive Pygott – WG 14, MISRA
– Tullio Vardanega – WG 9
– Patrice Roy – WG 21
– David Keaton – WG 14
Hubert Tong – WG 14

1 Opening activities

1.1 Opening Comments

1.2 Introduction of Participants/Roll Call

1.3 Procedures for this Meeting

1.4 Approval of previous Minutes (meeting 46, document N674)

Approved

1.5 Review of actions items and resolutions, Action Item and Decision Logs

1.6 Approval of Agenda [N 0680] ???

1.7 Future Meeting Schedule


2018





Pre-mtg 55

01/11/18



#54

TBD September 2018

CSA Toronto, Canada


#53

15-16/06/18

With WG 9 and Ada Europe


Pre-mtg-53

Teleconference



#52

TBD April 2018

Czech Republic with C


Pre-mtg 52

TBD March 2018


#51

22-23 January 2018

Phoenix, AZ


2017

pre-mtg-51

20/11/17

Teleconference (UTC 2000, 2 hr)


post-mtg-50

16/10/17

Teleconference (UTC 2000, 2 hr)


#50

17-18 August 2017

BSI London (with SC 22 Plenary)


#49

19-20 June 2017

Vienna, Austria with Ada Europe(2 day)


post-mtg-48

15/05/17

Teleconference (UTC 2000, 2 hr)


#48

6-7 April 2017

IBM Markham, Canada (2 day)


pre-mtg-48

Mar 6, 17

Teleconference (UTC 2100, 2 hr)

Post-mtg-47

13/02/17

Teleconference (UTC 2100, 2 hr)

Dedicated topic, Templates and Generics in Part 1, capturing C++ issues.

We discuss the number of meetings per year and the difficulty with finding funding. We decide to leave the meeting schedule as-is for 2017 but take a serious look at it in Aug at meeting 50.

Robert Seacord has scheduled a meeting on C secure and safe coding rules at the same time as meeting 48.

AI 47-02 Steve to write to R Seacord and see if we can have a joint meeting in Toronto in April.





2. Liaison Activities

2.1 SC 22 - Stephen

2.3 PL22.3/WG5 (Fortran) – Dan

2.4 WG4 (COBOL) – Chris Tandy

2.5 WG9 (Ada) - Erhard

2.6 PL22.11/WG14 C – David Keaton

2.7 PL22.16/WG21 (C++) - open

2.8 Ecma International, TC49/TG2 (C#) - open

2.9 Ecma International, TC39 (ECMAScript) - open

2.10 MISRA C - Clive

2.11 MISRA (C++) - Clive

2.12 SPARK - Joyce

2.14 SC27/WG3, WG4 Security - Stephen

2.15 Other Liaison Activities or National body reports

3. Document Review

We have a major decision to make about the class of documentation that we create. ISO is treating Technical Reports with distain, claiming that they only contain data that was used in the creation of standards. JTC 1 at its last plenary assigned TR 10000-1 to SC 7 to update and republish as an IS. A key point here is that SC 7 is republishing it as an IS without a New Work Item Proposal.

For discussion: It is likely time that WG 23 made TR 24772 (all parts) into standards vice TR’s. If we do this, do we want to repackage, or essentially send forward the current documents? Repackaging could see the .5 (Guidance) portions become normative and the other subclauses supporting informative material.

Stephen reports that, at the SC 22 teleconference of January ?? 2017, this issue was discussed and the secretary was given the task of communicating directly with JTC 1’s Technical Officer to find out the official position. Sally Seitz reported back that there is no issue and it is business as usual.

We decide to evaluate Part 1 with the view of how it could be converted to a standard. We discuss the notion of a meta-standard that addresses the processes to develop programs that satisfy rules that we develop. We would need to work with SC 7 (potentially) if we move into their scope of work.

No reliance on (a particular manifestation of ) “undefined behaviour” or “implementation-defined behaviour”. A conforming development can show that there is no occurrences of undefined behaviour.

We will return to this discussion after a review of existing documents.

3.1 TR 24772-1 Vulnerabilities, language independent

Document N0684,

Document N0686. We review the document and propose improvements. Results are captured in N0688. We discuss placement of REU and agree that it belongs in Clause 7, say 7.26, and move all other subclauses down by one. We give Erhard an AI to re-examine clause 7 and propose further refinements on clustering of similar vulnerabilities.


AI 47-03 – Erhard Ploedereder - re-examine clause 7 and propose further refinements on clustering of similar vulnerabilities.


AI 47-04 Clive Pygott - The problem as described [SYM] , sub-subclause 3, final paragraph – consider how C++ is affected.


AI – 47-05 Hubert Tong – Consider 6.41 [SYM] as templates and generics are designed in C++ and propose general wording to capture the current context.

AI 47-06 Joyce Tokar – Consider the AQSG as it applies to this document. If applicable, we will change the reference (to Wikibooks).

AI 47-07 – Clive Pygott, for 6.43.2 [BLP], 6.45.2 [BKK] There are significant JSF rules referenced but no MISRA C++ rules. Check.

AI 47-08 - Larry Wagoner– evaluate the guidance from clauses 6.X.6 and aggregate into a proposed list of top 10 language enhancements.

AI 47-09 – Stephen Michell – global edit on 6.X.6 to remove “standardization” and replace with “language design and evolution”.


We agree to freeze TR 24772-1 clauses, i.e. sub clause layout, titles and major content to provide stability for the language-specific parts. We identify that clause 6.40, Templates and Generics needs more work to capture C++-like issues and generalize them. There will be a dedicated teleconference on 13 February on this topic.

3.2 TR 24772-2 Ada language specific part

Document N0681. The Ada Part has been delivered by WG 9. Joyce Tokar assumes the role of editor. This version is missing 4 sections that we added in clause 6, plus the accumulated guidance in section 5. We also need to update a couple of titles, and Erhard is proposing new wording for failure modes.

We examine N068? And N0623 with the intention of asking HRG to review and incorporate a similar list as clause 5.2.

AI 47-10 Joyce and Erhard – review and rationalize the top N mitigation list in N0623 with a view to sending it to HRG.

3.3 TR 24772-3 C language specific part

Document N0686.

Notes from Paul Preney (Canada)

It seems to me that in N0665 (TR 24772-3 C), 6.15 Arithmetic Wrap-around Error there should also be some mention of:

Emphasize that signed integer over/underflows might trap on some systems.

i.e., It is imperative to ensure that all operations on signed integers will never over- or underflow.

Remind the reader that one cannot assume the underlying representation of signed integers.

Also in 6.24 Side-effects and Order of Evaluation of Operands in N0665, there is no mention of Annex C: Sequence Points --which IMHO should be added to the 2nd paragraph. Annex C nicely refers to the appropriate sections of the C standard where additional details are provided for the specific items.


From David Keaton:

      Deep vs. Shallow Copying... Stephen's note. I agree --but I would add that in C one should write a function to perform the correct and desired copying of a data structure. This is the best way, in C, to avoid issues when copying data. Thus, I would suggest the guidance should be to write a function to perform the copying of a data structure to avoid accidental incorrect copying of the data structure.

We add the basic guidance to N0688 as a bullet. This will be discussed at meeting 48 in April.


We discuss the concurrency vulnerabilities proposed. Changes agreed are in N0688. This effort was not completed and will be continued at a follow-on meeting, when David Keaton is present.

3.4 TR 24772-4 Python language specific part

Document N0592.

We are still waiting for updates from Santiago.

3.5 TR 24772-8 Fortran

Document [N0560] needs review.

3.6 TR 24772-X C++

Consider document [N0582]

We discuss plans for C++ vulnerability document.

There is a fundamental reliance upon Part 3 C that needs completion before we make too much progress on C++.


We discuss ways to handle the C subset that is part of C++.

The editor’s plan is to start with TR 24772-3 and examine each vulnerability description to identify C++ further restrictions and mitigations. For the vulnerabilities “not applicable” to C, consider how each of them apply to C++. Also to document in 6.X.2 how the user can use features of C++ to eliminate the vulnerability.


AI 47-09 Clive – Produce a framework vulnerabilities document (starting from Part 3 C) with obvious C++ differences and mitigations captured for meeting 48 in Toronto.


3.7 Spark Part

AI 47-01 Joyce – Copy the Ada Part to the Spark Part and make obvious adjustments, then send to Florian for rework.

3.8 Bibliography for each TR24772 Part

No discussion

3.9 Dirty Dozen Rules for C, generic, and other languages

AI 47-13 – All - Review how the rules are incorporated into Part 1 and Part 3. Consider the generic rules for other Parts.

4 Strategy (Face to face meetings only)

We consider how to address the needs of our larger community by moving the guidelines of TR 24772-1 clause 5.4 into a separate standard. The proposal on the table is to create a TR 24772-2 which is an IS that only contains this material (possibly expanded significantly) with references to TR 24772-1. The language-specific parts would slip in numbering, with Ada → Part 2, C → Part 3, etc.

AI 47-12 – Larry and Erhard – produce a draft IS 24772-X following the format of the current TR and populate with the material from 5.4

5 Publicity (Face to face meetings only)

Joyce proposes a user-guidance document that explains and promotes the work. Such a document could be a TR or could be a TR in the 24772 series.

Address the issue of API’s and how API designers can provide more security.

Another idea is to begin to develop guidelines for architecture, such as open computer buses in vehicles

Consider working with tool providers to give them a set of well-reasoned guidance, MatLab, Klockwork, etc

Consider working with other groups that promote security, such as Amazon.

How does this work with AADL and FACE (Future Airborne Capability Environment)

6 Other Business

6.1 Review of Assignment of responsibilities


7. Resolutions and Action Items

AI 47-01 Joyce – Copy the Ada Part to the Spark Part and make obvious adjustments, then send to Florian for rework.

AI 47-02 Steve to write to R Seacord and see if we can have a joint meeting in Toronto in April.

AI 47-03 – Erhard - re-examine clause 7 and propose further refinements on clustering of similar vulnerabilities.

AI 47-04 Clive - The problem as described [SYM] , sub-subclause 3, final paragraph – consider how C++ is affected.

AI – 47-05 Hubert Tong – Consider 6.41 [SYM] as templates and generics are designed in C++ and propose general wording to capture the current context.

AI 47-06 Joyce – Consider the AQSG as it applies to this document. If applicable, we will change the reference (to Wikibooks).

AI 47-07 – Clive, for 6.43.2 [BLP], 6.45.2 [BKK] There are significant JSF rules referenced but no MISRA C++ rules. Check.

AI 47-8 - Larry – evaluate the guidance from clauses 6.X.6 and aggregate into a proposed list of top 10 language enhancements.

AI 47-9 Clive – Produce a framework vulnerabilities document (starting from Part 3 C) with obvious C++ differences and mitigations captured for meeting 48 in Toronto.

AI 47-10 – steve – global edit on 6.X.6 to remove “standardization” and replace with “language design and evolution”.

AI 47-11 – Larry and Erhard – Produce a draft IS 24772-X following the format of the current TR and populate with the material from 5.4

AI 47-13 – All - Review how the rules are incorporated into Part 1 and Part 3. Consider the generic rules for other Parts.


8. Adjournment

Adjourned at 1600, 24 January 2017