[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, 23 Apr 2018, Lars Kurth wrote:
> Hi all,
> 
> On 06/04/2018, 15:13, "Lars Kurth" <lars.kurth@xxxxxxxxxx> 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!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.