[C-safe-secure-studygroup] Study Group Meeting Minutes - 20170308

Laurence Urhegyi laurence.urhegyi at codethink.co.uk
Tue Mar 14 13:40:23 UTC 2017


All,

Minutes from last week attached and also included in the body of the 
text below.


Action: Robert to put together a schedule which has the study group 
life-span lasting 3 years and distribute this to the list before the end 
of the month. Also submit to WG14.

Action: Clive, provide an update on the status of the hard copies when 
possible.

Action: Robert to update the group on the provision of PDF copies of 
MISRA-C when possible.

Action: Laurence to broadcast the new voting process to the mailing list 
group.

Here's the details for my action: during the meeting, it was decided 
that we would use the wiki for voting, after sending out the minutes, 
using a table in the wiki at the end of each rule where everyone is able 
to provide a vote. This opens the vote up to a wider audience of people 
who cannot make these meetings due to other commitments.

I'll send a further mail outlining exactly how to do this shortly.





## Topic
Review of actions from previous meeting.

## Key Points
* Some actions carried forward: see action log.
* Schedule required for Markham WG14 meeting.
* We could either present a schedule just for the life of the study 
group or the entire process.
* The study group will likely last between 2.5 to 3 years.
* Action: Robert to put together a schedule which has the study group 
life-span lasting 3 years and distribute this to the list before the end 
of the month. Also submit to WG14.
* This means we’ll bring our document to the Spring 2020 meeting.
* MISRA copies update: Action: Clive, please provide an update on the 
status of the hard copies when possible.
* Robert said that in his recent meeting with MISRA, he spoke with David 
Ward about provision of PDF copies, who said it has been possible in the 
past. Action: Robert to update the group on this in the next meeting 
after a further meeting with MISRA in between.



## Topic
Rule 1.1

##Key Points
* See the rule on the wiki for background information on the C standard 
and specifically the definition of a constraint.
* A violation of a constraint is undefined behaviour.
* Robert: this rule seems to be covered already by the C standard.
* Clive: there does need to be a statement somewhere that says ‘these 
are rules for the C language, as defined by this particular document’
* Robert: but can this be in the scope, earlier in the document, rather 
than a specific rule?
* Martin: it’s important to have a rule like this, because the 
definition in the standard on diagnostics is so weak: we should go 
further than their definition as we are concerned with safety and 
security critical systems.
* Robert: the C standard and TS 17961 just required a diagnostic, not 
what it looks like. For an analysis tool you’re never generating code, 
so there is no distinction between a fatal diagnostic, preventing code 
generation. and a warning, which allows code generation. Compilers are 
required to diagnose this and they do: so this seems an excessive 
requirement on the tools.
* Martin: I am not sure if I agree there - tools should be independent 
of compilers. The existing TS 17961 works in tandem with the compiler in 
diagnosis of certain rules.
* Robert: there is a second element to this rule: translations limits. 
It’s difficult to see how this rule would be violated - how does one go 
about exceeding the ‘implementation limits’, since they are imposed by 
the implementation itself.
* Roberto: a compiler can, at no obligation, exceed the limit of a given 
implementation, and only throw a warning, but allow compilation to 
continue. This is why this rule was included in MISRA-C.
* Robert: how well defined are these translations limits? Do they exist 
in the compiler's documentation?
* Roberto: in practice, the limit imposed is the minimum specified by 
the standard.
* Robert: In that case, we should write the rule closer to ‘the minimum 
limits of the standards’ not being exceeded. Secondly, it is possible to 
have programs which do not exceed these limits, yet still cannot be 
translated.
* Martin: yes, that would be fine - the concern would be if the compiler 
did translate incorrectly as a result of exceeding the limits: ie, if it 
introduced undefined behaviour.
* Robert: my point is that just because it does not exceed these limits 
does not mean that the program would be able to successfully translate 
it, so the program could be confused and generate undefined behaviour in 
the code, so this rule is inadequate to protect the safety of these 
systems.
* Martin: but regenerating invalid code would be a non conforming 
implementation: that is not allowed.
* Robert: but if it exceeded the minimum limits, then it could generate 
invalid code. So I suggest we should include the rule but restate it 
closer to ‘the minimum limits of the standards’ not being exceeded, 
rather than the implementation limits.
* Martin: my concern here is that we would be heading in the direction 
of requiring strict conformance, which is, in reality, impossible to 
achieve.
* Robert: that’s true, but it seems to be the current ‘state of play’. 
It seems as though the translations limits of the compilers are not well 
defined and not known by anybody, and so the analysis tools, because 
they don’t know, and they want to write this only once, so that it works 
with every compiler, are analysing based on the minimum requirements as 
per the standards and generate a diagnostic if it exceeds. Another thing 
that trips people up is that these are requirements for analysis tools, 
so a conforming tool would have to diagnose things that go over the 
minimum limits. That, in itself, is not a requirement for code: a code 
requirement could be relaxed and the tool is then used to see cases 
where a minimum limit has been exceeded. There is a risk in this method 
though because people come out with coding requirements that reflect 
analysis requirements.
* Martin: I agree with that. Targeting the C11 translation limits would 
simplify this requirement. If we require strict conformance then we need 
to also require a diagnostic of non-conformance.
This rule was then split into two and voted on: as a reminder, the vote 
is to include the rule in some form: the study group can, and most 
likely will, amend these rules.
* Joe: how do people at MISRA get a say in the inclusion of these rules: 
what if they don’t want rules to be included?
* Robert: ideally we could work together in these meetings and have them 
take part in the vote. They are on the mailing list and have access to 
the wiki. Clive is an indirect representative, at best, since he works 
with people at MISRA.
* Clive: there are two separate elements at play here: firstly we are 
looking at examples of safety critical rules and whether we want to 
include these kind of rules or not. This is independent of MISRA’s 
opinion. Secondly, we are looking at whether or not we want to include 
the rule exactly as it is now, in which case MISRA’s opinion is very 
important.
*Vote:* should the ‘constraint violations’ rule be included in the standard?
2 votes for
1 vote against
2 votes to abstain
*Outcome:* no consensus - see below.
* After this vote, it was decided that we would use the wiki for voting, 
after sending out the minutes, using a table in the wiki at the end of 
each rule where everyone is able to provide a vote. This opens the vote 
up to a wider audience of people who cannot make these meetings due to 
other commitments.
*Action:* Laurence to broadcast this decision and new process to the 
mailing list group.
Vote: should the translation limits’ rule be included in the standard?
4 votes for
0 votes against
1 vote to abstain
*Outcome:* consensus to include the rule.


## Topic
Rule 1.2
Discussion of this rule may be dependent on the proposal of how language 
extensions should be handled, from Gavin.

## Key Points
No discussion today. To be carried forward.



## Topic
Rule 1.3

## Key Points
No discussion today, awaiting post to the wiki.



## Topic
Rule 2.1

## Key Points
No discussion today, Jill was not present.



## Topic
Rule 2.3

## Key Points
* Martin: the phrasing of many MISRA rules is slightly ambiguous and 
could be more specific.
This rule applies to type definitions - there are existing checkers 
within compilers which detect violations of this rule.
It makes code easier to review and therefore does provide value in that 
sense.
* Robert: this fits in the category of rules where a violation is not a 
direct security problem, but could indirectly be a safety or security 
problem if it leads to less readable code, and Aaron’s assignment was to 
look at whether there was any data or research to support the assertion 
that unused code could result in safety / security problems.
* Clive: this rule is geared towards ‘suspicious behaviour’ - if there 
is something lying around unused in a codebase, should it be there, or 
has something been forgotten and is outstanding? Have you forgotten to 
complete something?
* Martin:  this rule requires analysers to diagnose violations at all 
scopes, local and global. Most compiling checkers only diagnose 
violations of this rule at a local level. Even though the rule provides 
an exception for 3rd party code and libraries, it does not provide the 
same exception for typedefs in headers belonging to modules in the same 
application. It’s common to treat a modular application as if it 
consisted of a number of 3rd party modules, even if those modules are 
developed in house or by another team. So the exception should be 
extended to ‘modules’ ie - the tool should not be necessarily required 
to document every single typedef at global scope in a program - maybe if 
listed in header file then it should be listed, but really, diagnosing 
every single unused typedef in a program does not seem very useful.
* Robert: is this rule potentially only relevant for safety critical and 
not security critical, perhaps?
* Clive: it’s relevant for safety critical.
* The 3 profiles of the study group were then re-capped: Safety, 
Security, Safety and Security. Any rule in the document may be in one, 
two or all three profiles. So this could potentially be a rule which is 
only a Safety rule. We’ll do this assignment of rules to profiles later 
on in the life of the study group.
* Robert: not sure if we need to vote on this one, it feels very similar 
to all the other MISRA rules that deal with not including unused 
elements of code.
*Vote:* we did not take a vote on this rule today.




## Topic
Rule 2.4 (no consensus last time).
Discussion of this rule may be dependent on the further investigation 
into diagnosing unused code.

## Key Points
We did not reach this point: to be carried forward.




## Topic
Rule 2.6

## Key Points
We did not reach this point: to be carried forward.




## Topic
Rule 2.7

## Key Points
We did not reach this point: to be carried forward.




## Any Other Business
SafSec Action Research Day 31st October at the BCS entitled:
7 years on SafeSec Software is a common expression - do the Cloud and 
IoT make a difference?

## Key Points
Adele was absent today: to be carried forward.



## Topic
Summary of all actions from today’s meeting.

## Key Points
See the top of the email.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CSafetyandSecurityStudyGroupMeeting-AgendaMinutes-v1.0-20170308.pdf
Type: application/pdf
Size: 96588 bytes
Desc: not available
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170314/307482de/attachment-0001.pdf>


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