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

RE: Xen FuSa meeting tomorrow Tue 17 November


  • To: Francesco Brancati <francesco.brancati@xxxxxxxxxxxxx>
  • From: Piotr Serwa <pserwa@xxxxxxxxx>
  • Date: Thu, 19 Nov 2020 07:50:15 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=exida.com; dmarc=pass action=none header.from=exida.com; dkim=pass header.d=exida.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ypUrAoyTfDRzbWigw48+nnv3fwTi6SQiKcMophUCY78=; b=oHqh42H7IKHnF3r/1mUhTVKoFG3i5pcTzJXOfxHm5QVJe3es6FEnciFQtfmWfP8hi9wfyvlPsCx9+PITmYFDWvJ4pOtWIgohWct5yrEiZfLndpf9wwnftZvCK9tmzBW4FsKA0VlJVq0V2ZuovBHW9TjWC000ebbpeDcqkRcuJTQp6JjrBy10RCFF9DvSxxnM9wEDHsvCQqReXQ3D4g77lg3mkFq1YgtZABZiIdW3BfwnBLCKA8xBBLJiVyYDUI177e/Mrdn41oEHlFkl4RR0Mn81hkXbYczx7Hnenc7MFOUGzwAH9xrqe6Fk9fSSKPXrdFcP6b8X2OJqrJs57pTMjw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LvEBPgdDgBmilYpffsoaFhbymH9Apv7VOdrVOl9lAWNXI6DPo4gWfv7Ths8qIDFsNqn6FOdhyBFkw+AVb219QxBNcZ5z5mUVCXvVRX6FUVw9HQyfQoqEQQcLAmLmigDFFcyeHGKpZwP7x9kbGRT0D+eTrZ2kWAYx/XjB9iR10TVwrC9o/klAkqiWRHxgO21NEkZgOLEQN+ewXWvJqACi82cxtlyRkzTDWn68n87vm5V8F3iwtZwFftROrmebIMPwnfPCZcGB/9kJxhoCpIUumK1YuF7d8bbFOuk0SLdW+NCmbkpdHfZOstlTghMTxQanRF+raDnyBLGiN2RXURJ7IA==
  • Authentication-results: resiltech.com; dkim=none (message not signed) header.d=none;resiltech.com; dmarc=none action=none header.from=exida.com;
  • Cc: Michał Szczepankiewicz <mszczepankiewicz@xxxxxxxxx>, "fusa-sig@xxxxxxxxxxxxxxxxxxxx" <fusa-sig@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 19 Nov 2020 07:50:22 +0000
  • List-id: This is a discussion list for members of the Xen Project FuSa SIG <fusa-sig.lists.xenproject.org>
  • Msip_labels: MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_ActionId=3fb6682c-4c3a-47f9-90c5-0eaa3f68e5e8;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_ContentBits=0;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_Enabled=true;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_Method=Standard;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_Name=Public;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_SetDate=2020-11-18T16:16:57Z;MSIP_Label_747f934f-5383-4a4c-9722-3a8c30f10e24_SiteId=a746f28d-d05f-4510-82c7-78d250c008ca;
  • Thread-index: AQHWvGrAP6ImaiuRHUOhLirPpqyYbKnML5WAgAAfhoCAAA+4AIABNe0ggAAzy4CAAEsZcA==
  • Thread-topic: Xen FuSa meeting tomorrow Tue 17 November

Hi Francesco, David,

 

I know that Linux is scanned by Coverity as it is open source project, but it is in their cloud and not on linux servers. According to their coverage report they cover MISRA quite well.

 

I guess you would need to negotiate it with tool vendors if you want it for free on your servers integrated with your CI – but well, Perforce is a project member, right 😊 ?

 

David, I agree that one should not just on marketing slides and see if there is a checkbox saying that a rule is covered. It is not that it just covers one rule or it does not – especially as directives are not decidable. The certificate or the assessment report can be analyzed too (if available), this typically shows the details of coverage of each rule. A well selected commercial tool, possibly running in parallel with open-source static analysis  (a subset of what you have in powerpoint) would give a sufficient MISRA coverage.

,

Concerning the on-premise execution (integrated with the CI) – I assume this is provided by most of commercial tools (at least I’ve seen them working that way). Running on cloud (like Coverity for linux) is nice that you have a good dedicated web interface to errors. I don’t know if it is triggered manually or automatically. But I guess you cannot block the build or report within the build that misra violations are found.

 

Concerning other checks – it is not just misra that you want to verify I guess. Tools from your presentation detect way more, so you need to agree on what you check otherwise you will be overloaded with warnings from those tools that you know that can be ignored (e.g. using of C extensions). After all, if you comply to the agreed rules, you don’t want that any tool reports any issue.

 

Some of the tools that you listed (like frama-c or klee) are  mainly for detecting runtime errors (like division by 0, buffer overflow), rather than coding gudelines. I think it is also good to use it, alternatively I  would recommend a commercial tool Astree C (which by the way covers both misra and runtime analysis by abstract analysis).

 

 

Regards

Piotr

 

 

 

From: Francesco Brancati <francesco.brancati@xxxxxxxxxxxxx>
Sent: Wednesday, 18 November 2020 12:48
To: Piotr Serwa <pserwa@xxxxxxxxx>
Cc: Michał Szczepankiewicz <mszczepankiewicz@xxxxxxxxx>; fusa-sig@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Xen FuSa meeting tomorrow Tue 17 November

 

Dear Piotr,

of course commercial tools offer much more features. Do you think their licenses would allow the usage server side to support a community based development?

I guess we were focusing on free tools to overcome this issue.

@Stefano do we have any constraints in adopting a commercial tool?

Regards,

Francesco.

Il 18/11/2020 11:39, Piotr Serwa ha scritto:

Hi Francesco,

 

Why not taking a commercial tool, with a full MISRA 2012 support? Free tools are far below the needs, I think. Commercial tools typically come with qualification kits and safety certificates. I would recommend investigating Axivion, Parasoft C test , Helix QAC, LDRA TBvision or Absint rule checker. Maybe you can negotiate a free usage as Xen is open source. Coverity is doing this approach (I mean free scan of Linux code).

 

Regards

Piotr

 

From: Fusa-sig <fusa-sig-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Francesco Brancati
Sent: Tuesday, 17 November 2020 15:14
To: fusa-sig@xxxxxxxxxxxxxxxxxxxx
Cc: Lorenzo Falai <lorenzo.falai@xxxxxxxxxxxxx>
Subject: Re: Xen FuSa meeting tomorrow Tue 17 November

 

Dear all,

please find attached the result of our investigations on sonarQube and alternatives.

the outcome can be summarized in this way:

SonarQube (sonarcloud) could be a valid tool for our needs because it supports command line and serverside precommit operations and should support inline justification of violations. Unfortunately (as pointed out also by Artem) MirsaC support is really limited.

we provide a list of alternatives (cppcheck is in the list) but support to serverside precommit checks must be further investigated.

talk to you later,

Francesco and Lorenzo.

Il 17/11/2020 14:17, Bertrand Marquis ha scritto:

Hi Artem,
 
Here after you will find the current status I got on your tickets.
 
On 17 Nov 2020, at 11:24, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx> wrote:
 
Hello all
 
Few notes on my AIs to discuss today:
 
- Sonar, unfortunately, support a very limited set of MISRA rules (https://rules.sonarsource.com/c/tag/misra-c2012) so it is not suitable for us. OTOH, cppcheck has a full set of MISRA-C-2012 143 rules supported via public plugin (without publishing rules text, only giving an ID) https://github.com/danmar/cppcheck/blob/main/addons/misra.py. I think this should be a great starting point so will try it now.
 
- We have created a migrated armclang Xen branch on top of current staging, but I cannot check it without license for Arm DS safety compiler, unfortunately. Also I have re-checked Arm Safety Compiler issues after migration to new support system (except one), here's the list:
 
I am working on that and will keep you informed.
 
CAS-138402-Y0Y9C3 --- 00195992
 
This is not considered a bug but a feature request and for now this is considered.
 
CAS-137352-T7F4V1 --- 00192196
 
This a known limitation and there is a workaround for it.
 
CAS-138292-L5S0V0 --- cannot find it yet
 
There is a workaround for current compiler and this will be fixed in the new compiler scheduled to be released around H2 2021 
 
CAS-137357-Z7W3B8 --- 00182044
 
This has been resolved in 6.6.4 version of the compiler.
 
CAS-137359-V7G6W6 --- 00118170
 
This is a limitation of the fromelf tool and is considered a feature request. It has not been considered yet.
 
BR
Bertrand
 
 
BR,
-- Artem
 
-----Original Message-----
From: Fusa-sig <fusa-sig-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Stefano Stabellini
Sent: Tuesday, 17 November, 2020 00:49
To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
Cc: fusa-sig@xxxxxxxxxxxxxxxxxxxx; stefanos@xxxxxxxxxx
Subject: Xen FuSa meeting tomorrow Tue 17 November
 
Hi all,
 
I would like to remind you that tomorrow it is time for our Xen FuSa SIG meeting. There are a number of outstanding actions, see below. Also, David Ward kindly volunteered to present on the subject of the MISRA Compliance 2020 document, which is extremely relevant as it provides a framework to manage deviations.
 
Cheers,
 
Stefano
 
 
 
On Tue, 3 Nov 2020, Stefano Stabellini wrote:
Hi all,
 
These are the minutes of today's FuSa meeting.  Look for "ACTION" in 
the test to find the ACTION items.
 
Cheers,
 
Stefano
 
 
 
# Build Xen with ARMClang
 
Bertrand: ARM will internally build Xen with ARMClang to validate 
ARMClang against Xen. It is going to start in the next couple of months.
 
Artem: I have opened a bunch of issues against ARMClang. What is the 
status?
 
Bertrand: will check
 
ACTION(Bertrand): ARM to let us know when issues are going to be fixed 
and in which version of the compiler.
 
ACTION(Artem): send the ARMClang series for Xen again rebased on 
staging
 
 
# Resiltech presentation on MISRAC
 
First identify set of rules we have to comply to MISRAC. A subset of 
MISRAC, but which one?  Some rules are mandatory, some others are 
advisory?
 
Who is responsible for deciding which rules are mandatory (R1)? It is 
important to have the safety experts involved.
 
Once we identify the R1 rules, let's use static analysis to check for 
violations. For instance SonarCloud.
 
We need to device who is responsible for fixing the violations, and 
what happens when developers say that the solution is worse than the 
original code.  There is a need for a final pass by a safety expert 
after the developer's analysis. In case the safety expert team 
identifies that the justification cannot be accepted the code has to be fixed.
 
 
We need a tool able to process justifications for MISRAC violations 
inline with the code. It is important to maintain MISRAC violation 
justifications in sync with the code. Is there a tool that can do that 
today?
 
If the tool doesn't support it, we could add scripting to it, so that 
we could extract the justifications from the comments and populate the 
tool's database ourselves.
 
 
ACTION(Artem): work with Sonar and see how it handles justifications
ACTION(Francesco): do an analysis on the tools and justification 
handling
 
 
ACTION(Stefano): MISRAC justifiaction as incode comments, is it viable
                from a community perspective? Start the discussion.
ACTION(Stefano): Diagram to describe the new contributor process
                workflow
 
 
MISRAC document to provide a framework to manage deviations 
https://urldefense.com/v3/__https://www.misra.org.uk/forum/viewtopic.p
hp?f=241&t=1842__;!!GF_29dbcQIUBPA!lHt1TEb2koDpfOmJwNiV5B-0OQc3sCB429nx6W4sPDUdbXiz2C5WGp3Wh-tSKeddKg$ [misra[.]org[.]uk] ACTION(David Ward): do a presentation on the topic during the next
                   FuSa meeting.
 
 

--

Francesco Brancati
Innovation Manager and SW Solutions Expert
Email: francesco.brancati@xxxxxxxxxxxxx
Phone: +39 0587 21 24 65 (internal number: 104)
Mobile: +39 333 48 52 041
Skype: francesco.brancati

www.resiltech.com


This e-mail and related attachments are property of ResilTech S.r.l. and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You shouldn't copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Questa e-mail e tutti i suoi allegati sono proprietà di ResilTech S.r.l. e possono essere soggetti a restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.

--

Francesco Brancati
Innovation Manager and SW Solutions Expert
Email: francesco.brancati@xxxxxxxxxxxxx
Phone: +39 0587 21 24 65 (internal number: 104)
Mobile: +39 333 48 52 041
Skype: francesco.brancati

www.resiltech.com


This e-mail and related attachments are property of ResilTech S.r.l. and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You shouldn't copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Questa e-mail e tutti i suoi allegati sono proprietà di ResilTech S.r.l. e possono essere soggetti a restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.


 


Rackspace

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