Re: Xen and safety certification, Minutes of the meeting on Apr 4th (Notes on MISRA, ISO 26262 static code analysis requirements)

Re: Xen and safety certification, Minutes of the meeting on Apr 4th (Notes on MISRA, ISO 26262 static code analysis requirements)

[Lars Kurth]

Hi all,

On 06/04/2018, 15:13, "Lars Kurth" <lars.kurth@citrix.com> wrote:
     
    > 1) Requirements to the code, a subset of MISRA for ASIL B
    > Next step: get more information about requirements and publish it to
    > xen-devel.
    
    I see a few problems here:
    
    * The MISRA 2012 spec has to be bought and it is rather big (100's of pages): 
    so, I don't think it is practical to work from the spec
    
    * Some coding style patterns will likely be perceived as odd and unreasonable 
    by community members: as some common code would be affected we cannot 
    treat this in isolation say on ARM only. Although it is recognized that some of 
    the coding style patterns may not make sense, compliance to MISRA is 
    necessary and cannot normally be discussed away.
    
    * PRQA has set up an environment and initial MISRA compliance report for a Xen on ARM build 
    ** The question is what (if anything) can be shared publicly
    ** The other open question is whether we can come to some sort of longer term agreement between the Xen Project and PRQA to use their tools
    ** As an aside, what PRQA have done would need to reflect what we do in step 2 is. We also want to minimize the work for PRQA: in other words, it has to be very simple to enable the minimal config coming out of task 2 such that PRQA can 
    ** As far as I recall 90% of all MISRA violations come down to around 70 issues. A large number are in tools
    ** Also, I believe that MISRA compliance tools will likely lead to a large amount of false positives, due to the distributed nature of Xen: process boundaries, kernel/user space boundaries, etc. would all lead to false positives, which somehow have to be managed.
    
    ACTION => Lars to follow up with Paul Luperto from PRQA
    
Hi all. I had a good meeting with Richard and Paul from PRQA today and it looks like we came up with a workable plan. There are a few things that will need checking, but this should be done in about 2 weeks. 

In essence there is a possibility for PRQA to make an instance of their QA·Verify Management Dashboard (see http://www.prqa.com/static-analysis-software/qa-verify/) to a small number (to be agreed) of community members initially on a suitable baseline for Xen on ARM (I would say Xen 4.11 or an RC would be a good starting point). I believe access should be restricted to committers, maybe people which committers delegate work to. After all, we want to enable an upsell route for PRQA, in return for providing a free service to the community. 

In any case, this would allow us to use the tool to follow the process I laid out above and get started.

Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen and safety certification, Minutes of the meeting on Apr 4th (Notes on MISRA, ISO 26262 static code analysis requirements)

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2781 bytes --]

On Mon, 23 Apr 2018, Lars Kurth wrote:
> Hi all,
> 
> On 06/04/2018, 15:13, "Lars Kurth" <lars.kurth@citrix.com> wrote:
>      
>     > 1) Requirements to the code, a subset of MISRA for ASIL B
>     > Next step: get more information about requirements and publish it to
>     > xen-devel.
>     
>     I see a few problems here:
>     
>     * The MISRA 2012 spec has to be bought and it is rather big (100's of pages): 
>     so, I don't think it is practical to work from the spec
>     
>     * Some coding style patterns will likely be perceived as odd and unreasonable 
>     by community members: as some common code would be affected we cannot 
>     treat this in isolation say on ARM only. Although it is recognized that some of 
>     the coding style patterns may not make sense, compliance to MISRA is 
>     necessary and cannot normally be discussed away.
>     
>     * PRQA has set up an environment and initial MISRA compliance report for a Xen on ARM build 
>     ** The question is what (if anything) can be shared publicly
>     ** The other open question is whether we can come to some sort of longer term agreement between the Xen Project and PRQA to use their tools
>     ** As an aside, what PRQA have done would need to reflect what we do in step 2 is. We also want to minimize the work for PRQA: in other words, it has to be very simple to enable the minimal config coming out of task 2 such that PRQA can 
>     ** As far as I recall 90% of all MISRA violations come down to around 70 issues. A large number are in tools
>     ** Also, I believe that MISRA compliance tools will likely lead to a large amount of false positives, due to the distributed nature of Xen: process boundaries, kernel/user space boundaries, etc. would all lead to false positives, which somehow have to be managed.
>     
>     ACTION => Lars to follow up with Paul Luperto from PRQA
>     
> Hi all. I had a good meeting with Richard and Paul from PRQA today and it looks like we came up with a workable plan. There are a few things that will need checking, but this should be done in about 2 weeks. 
> 
> In essence there is a possibility for PRQA to make an instance of their QA·Verify Management Dashboard (see http://www.prqa.com/static-analysis-software/qa-verify/) to a small number (to be agreed) of community members initially on a suitable baseline for Xen on ARM (I would say Xen 4.11 or an RC would be a good starting point). I believe access should be restricted to committers, maybe people which committers delegate work to. After all, we want to enable an upsell route for PRQA, in return for providing a free service to the community. 
> 
> In any case, this would allow us to use the tool to follow the process I laid out above and get started.

Fantastic!

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel