[C-safe-secure-studygroup] proposed report to WG14

Wilson, Charles Charles.Wilson at draeger.com
Wed Oct 16 13:34:32 BST 2019


The following is my proposed report to WG14 on our status.

 

 

Based on the feedback from the last WG14 meeting, TS17961 had discussions as
to how to best proceed given the impasse over usage of MISRA C materials as
the basis of future documents.

 

We strongly believe that there is value to WG14 to provide safety / security
recommendations to the C community.

 

We considered five (5) options:

1.	update existing security rules for C18 / parallelism
2.	cooperative standard for security and safety
3.	define unspecified / undefined safety behavior (type safety)
4.	fix annex K
5.	annotate annex K

 

We settled on a proposed approach which would focus on option 1, 3, and 2
(in that order).

 

More specifically the options would entail:

 

1.	update existing

a.	review of TS17961 for any changes needed to bring it into line with
C18
b.	consider proposals for new rules, such as in the area of parallelism
- but not limited to that

2.	cooperative standard

a.	how to handle any incompatibilities. In London it was suggested
there was at least one, but this hasn't been pinned down
b.	recognise different usage models and how that impacts the rules to
be applied. TS17961 was written with the aim of being applied to existing
code, so there were concerns over 'noisy' rules that would generate too many
'false positives'. By contrast, MISRA is written with the expectation that
the rules will be applied during development, so the 'noisy' constructs
never get written into the code. However, these are not exclusive concerns.
It would be useful to consider the development of secure applications and
there are times were a safety system may be looking to adopt existing code -
particularly at low SIL (Safety Integrity Level - see ISO 61508).
c.	a particular concern regarding the adoption of existing code is what
to do with libraries. MISRA currently says libraries should be developed to
the same standard as the rest of the code, but this is often impractical.
There has to be some argument that the conservative use of a
well-established library is safer than the production of new code to do the
same job. The revision of MISRA C++ is finding this challenging, as we keep
wanting to make exceptions for libraries, e.g. 'no unused type definitions
or functions in a project, unless introduced by a library header'

3.	define unspecified / undefined

a.	The idea for this topic largely came from the suggestions from
Martin Sebor, that the compiler could provide specific warnings where
unspecified behaviour would make the code unpredictable or unportable - for
example, the order of evaluation of subexpressions is UB, but usually it has
no impact on the behaviour of the program. The only time it does is if two
or more subexpressions access the same variable and at least one of them
modifies it.  There'd still be arguments about what to do if one of the
subexpressions is a function pointer. Does the tool need to track all
functions that may be assigned to the pointer, or take the pessimistic
assumption that it will access a common variable, or take the optimistic
view that it won't?

 

To get a sense of the effort for item 3, we began categorizing the undefined
behaviors in C18.

 

As membership has been an issue in the past, we have reached out to INCITS
in order to broadcast a call-for-participation.

 

Additionally, we have reached out to INCITS to determine the sales figures
for the TS17961 document itself.

 

 

 

Charles Wilson

Senior Architect

Dräger Medical Systems

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20191016/4c8c78d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5756 bytes
Desc: not available
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20191016/4c8c78d2/attachment-0001.bin>


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