[C-safe-secure-studygroup] MISRA Rule 15.5 functions shall have a single point of exit

Robert Seacord rcseacord at gmail.com
Fri Oct 6 15:49:40 BST 2017


Thanks Clive.  My earlier point was that I'm not sure we are immune to this
standard in the US either, since it's an international standard and I'm
sure it's one that many of our industries have adopted.  I doubt we've
enshrined it into law because we don't care for no Gobermint regulations.

We might have to include such a rule in a safety profile. From a coding
perspective, I think it is a bad practice because it forces you to write
code that is hard to read, hard to understand, and consequently more prone
to error.  I know we had no such rule in the CERT C Coding Standard and we
have many examples of "Compliant Solutions" which violate this rule.

I believe the genesis of this rule was always in analyzability, so it is
likely the analysis vendors who should be able to comment on how necessary
this constraint is today for code analysis.  It's definitely impossible to
adopt this rule for security.

Also, for LOLZ take a look at technique 5 in B.1 "Limited use of pointers".

rCs

On Fri, Oct 6, 2017 at 10:14 AM, Clive Pygott <clivepygott at gmail.com> wrote:

> Having looked into it 'single point of exit for functions' is explicitly
> in IEC61509-3 (see table B.9 "Modular Approach" attached). I admit my copy
> is old (2002) but as MISRA were still quoting it in 2012 I'm guessing its
> still there
>
> How embedded it is in EU law, I'll leave to the lawyers.  Certainly if you
> look at the UK Health and Safety Executive's website, their advice pretty
> much all has 'shall be 61508 compliant'  written into it (HSE is the
> government body that investigates and potentially prosecutes after an
> accident). I believe that this is a common pattern for all EU government
> safety bodies.
>
> Strictly, as can be seen in table B.9, the single point of exit isn't
> mandated, but is Highly Recommended - defined as "the technique or measure
> is highly recommended for this safety integrity level. If this technique or
> measure is not used then the rationale behind not using it should be
> detailed during the safety planning and agreed with the assessor". On most
> projects I worked on that was following 61508, the starting point was 'if
> its HR, we're doing it'
>
> All the best
>
>     Clive
>
>
> For Information:  table B.9 is referenced off table A.4 "Software design
> and development", which also references table B.1 "Design and coding
> standards", which may be of interest to us. These are also attached
>
> Also FYI: SIL is Safety Integrity Level. This is the result of a risk
> assessment process that combines the severity of a potential accident
> involving the system under development and how likely it is to occur. SIL1
> is (roughly) occasional minor injury to SIL4 (any) death. Architectural
> design (like diversity) can reduce the SIL of a subsystem
>
> [image: Inline image 3][image: Inline image 1][image: Inline image 2]
>
>
>
>
>
>
>
>
> On Thu, Oct 5, 2017 at 5:33 PM, Robert Seacord <rcseacord at gmail.com>
> wrote:
>
>> Why is IEC61508 a European standard?  I though the IEC was an
>> international standards organization,
>>
>> Can you share the text from the standard which establishes this
>> requirement?  I would be surprised if this standard specifically addresses
>> C language, so I'm guessing MISRA interpreted a more generally requirement.
>>
>> On Oct 5, 2017 5:00 AM, "Clive Pygott" <clivepygott at gmail.com> wrote:
>>
>> Hi
>>
>> Am I right that we've already discussed 15.5 (at least in passing,
>> possibly when discussing Rule 16.3 - all switch clauses will end with a
>> break or throw) and concluded that only allowing a single return in a
>> function is overly restrictive?  - which I'd agree with.
>>
>> I'm in a MISRA meeting at the moment and this has come up and I've
>> discovered that there is a good reason for the rule - as its a specific
>> requirement in IEC61508  (the European generic safety management standard).
>> This is written into European law, so all of us developing systems in
>> Europe are required to comply with this requirement - so the MISRA rule is
>> there to ease legal compliance.
>>
>>     Clive
>>
>>
>>
>> _______________________________________________
>> C-safe-secure-studygroup mailing list
>> C-safe-secure-studygroup at lists.trustable.io
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-s
>> ecure-studygroup
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20171006/b31859ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table B9.png
Type: image/png
Size: 35197 bytes
Desc: not available
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20171006/b31859ab/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table A4.png
Type: image/png
Size: 51149 bytes
Desc: not available
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20171006/b31859ab/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table B1.png
Type: image/png
Size: 49366 bytes
Desc: not available
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20171006/b31859ab/attachment-0005.png>


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