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

Re: [XEN PATCH][for-4.19 v2] xen: Add SAF deviations for MISRA C:2012 Rule 7.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 23 Oct 2023 08:34:16 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q1tFomd5FlTyvWlPsc9890A4p9Pm8Be/F/j2GShjuUQ=; b=ZDDZx7y2IcHnrjx9PiS17f3kNyl4Jate+bOpSRUbUs4WbI4XJmYXMfbAPhF9day4dWSO7IpAK/O/mhKuISybO4BJoI4Q/mhAIZLTFCpafqMumin2A1OLroIr4P8u6GKcMMJkN+H80y7TVSBsczcYG0B51+skuNhK78crQXZnuI85BecMq/9eoqU89xflGGIzcvlrWTwJQV0Jj85jFrg4coelziRgobY88HD9A9GTfwHRQAxWvPbksWPf9IfJ+b3J/KMBNwg6h70LF8OCmG2JiO+OwvGL8cOhKJwjfh+8EUp1ua8Tg8Mh4/cF+bBviEwNPpzXR5WO5rGKfAhPOCKNBg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Za04EurTx+enGMledJZWjIhIVk423XQhU7kmIXc4/MQDYk/PoWGBflm4FY6fMGFr1Zm+bIlJKUtMHKYuNfRMtwtuYdtDihucREbL7f8UMnl1GPFuad1oBLnsYhf0G684WSrDLOzq8BvmwBUs77Hdl4a2e83AxhGuInkleK+gnGcPzZXL4WCBQv8f0zx7H9BNYFcCvEOuXYfNdYj9AdQK9N3tXDKfh24U522qchIQuniXVu856THv2Mu7HviDwnVrKiN5ExJwgDQW9H7skUASYR2p+vRKzOHhwCwnlwZAduoMFPgO3OZynU7hUYs5XQCA8cDFDR2LNaMkOiwrU6gOCw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 23 Oct 2023 06:34:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20.10.2023 16:58, Nicola Vetrini wrote:
> On 20/10/2023 15:24, Jan Beulich wrote:
>> On 20.10.2023 12:33, Nicola Vetrini wrote:
>>> On 20/10/2023 08:38, Jan Beulich wrote:
>>>> On 19.10.2023 18:34, Nicola Vetrini wrote:
>>>>> On 19/10/2023 17:57, Jan Beulich wrote:
>>>>>> On 19.10.2023 13:04, Nicola Vetrini wrote:
>>>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>>> @@ -85,10 +85,10 @@ conform to the directive."
>>>>>>>  # Series 7.
>>>>>>>  #
>>>>>>>
>>>>>>> --doc_begin="Usage of the following constants is safe, since they
>>>>>>> are
>>>>>>> given as-is
>>>>>>> -in the inflate algorithm specification and there is therefore no
>>>>>>> risk
>>>>>>> of them
>>>>>>> -being interpreted as decimal constants."
>>>>>>> --config=MC3R1.R7.1,literals={safe,
>>>>>>> "^0(007|37|070|213|236|300|321|330|331|332|333|334|335|337|371)$"}
>>>>>>> +-doc_begin="Octal constants used as arguments to macro INSTR_ENC 
>>>>>>> or
>>>>>>> MASK_EXTR
>>>>>>> +can be used, because they appear as is in specifications, 
>>>>>>> manuals,
>>>>>>> and
>>>>>>> +algorithm descriptions."
>>>>>>> +-config=MC3R1.R7.1,reports+={safe,
>>>>>>> "any_area(any_loc(any_exp(macro(^(INSTR_ENC|MASK_EXTR)$))))"}
>>>>>>
>>>>>> INSTR_ENC() is a local macro in x86'es AMD SVM code. A macro of the
>>>>>> same
>>>>>> name could imo be introduced without issues in, say, Arm code. The
>>>>>> above
>>>>>> would then needlessly suppress findings there, aiui.
>>>>>>
>>>>>> MASK_EXTR() otoh is a global macro which ise used for various
>>>>>> purposes.
>>>>>> Excluding checking there is imo going too far, too.
>>>>>
>>>>> I should have thought about it; I can simply enforce the deviation 
>>>>> to
>>>>> additionally match
>>>>> only a specific file for each of the macros.
>>>>
>>>> That'll work for INSTR_ENC(), but not for MASK_EXTR().
>>>>
>>>
>>> Why? What I'm deviating is reports due to octal constants used in
>>> expressions
>>> that contain MASK_EXTR in their expansion if and only if these are
>>> located in the
>>> file svm.h.
>>> No extra octal constant will match all these constraints.
>>
>> New MASK_EXTR() uses can appear at any time, without necessarily
>> matching the justification.
>>
>> Jan
> 
> Sorry, but I don't understand what's your concern exactly. With the 
> improvements I proposed
> (hence a new patch revision) I see the following possible future 
> scenarios:
> 
> 1. an use of MASK_EXTR() in a file other than x86/hvm/svm/emulate.c 
> appears, with no
>     use of octal constants in the expansion. This won't be deviated;
> 2. an use of MASK_EXTR() in x86/hvm/svm/emulate.c appears, with no use 
> of octal
>     constants in the expansion. This won't be deviated;
> 3. an use of MASK_EXTR() in x86/hvm/svm/emulate.c appears, with octal
>     constants in the expansion. This will be deviated;

This is what I'm concerned of: How do you know up front whether such new
uses want deviating?

Jan

> 4. an use of any other macro with an octal constant in its expansion 
> won't be deviated,
>     unless the configuration is suitably edited.
> 
> Does this address your concern?




 


Rackspace

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