From nobody Wed Feb 5 12:56:07 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=bugseng.com ARC-Seal: i=1; a=rsa-sha256; t=1736418117; cv=none; d=zohomail.com; s=zohoarc; b=IlLg07izm2q6tVudZp+FLwRK+hxZBigSz+4GEJ9FOXuRDc2pDd6H4x6D2L7LxFESI/5t2n3J2D5EAspCCKt1x8Cnv8mptVmrFra6oKGZWEkK7qZeNnIiU3MSq3H8NgYKA3Hgf8KpNFU+xsld5z0x+10cEC2BldIL0IhAZKsIaWQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1736418117; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=Rq2G8vQOha7Of9Iw0EnH2nZ8dagbpgrnSx86E6ATO40=; b=FT9mBNX9VCB06Rl+jBgwCCDCjIhdDZXTwSJbtMMp7AJMIai3+BEUiYTWkWDYhkN0t+swubFvuu+z/r1XB/79XXPnJ5xszUYmy2KRuLuTNjm0+X9iPy6tY52fvlNtMqWbctD8PotTM5zSn4+IGu1RiMur79CXKDPVqPJ2plQXrn4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1736418117322824.12648532584; Thu, 9 Jan 2025 02:21:57 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.868038.1279573 (Exim 4.92) (envelope-from ) id 1tVpfY-0003Lf-K2; Thu, 09 Jan 2025 10:21:40 +0000 Received: by outflank-mailman (output) from mailman id 868038.1279573; Thu, 09 Jan 2025 10:21:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tVpfY-0003LY-HB; Thu, 09 Jan 2025 10:21:40 +0000 Received: by outflank-mailman (input) for mailman id 868038; Thu, 09 Jan 2025 10:21:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tVpfX-0003Km-Ae for xen-devel@lists.xenproject.org; Thu, 09 Jan 2025 10:21:39 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 821c174f-ce73-11ef-a0df-8be0dac302b0; Thu, 09 Jan 2025 11:21:37 +0100 (CET) Received: from delta.homenet.telecomitalia.it (host-87-20-204-41.retail.telecomitalia.it [87.20.204.41]) by support.bugseng.com (Postfix) with ESMTPSA id 52E314EE0738; Thu, 9 Jan 2025 11:21:32 +0100 (CET) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 821c174f-ce73-11ef-a0df-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail; t=1736418096; bh=ZzTypflkqDi+3QAuJnRK3p/CkVQ1Vt55alRN2zi1QhI=; h=From:To:Cc:Subject:Date:From; b=i0P+BsIsnH3otBjj6iLCGC0ZW22C8IglQU2+ftVzuBODo4OYihv4xzKuFiQoi1OJO beCi4qTOvtg89LDpoVpxjBsGXWYME7hXW9IIlBZQX5BnXh/URNLro81G9bGhakhhe3 VeQmUQqY5GJFuQTCeVFI8FSEKPKoqToN8bwmRdqiTZM/tAZ19235PSdYwg7cqXT6CC 0XW/m7dQyFSR+0mP3iDQAJTy6o0yCh+KLYlsDNK3JqTW0Nzg7QHPoQ5Q891VqdwdOz eXkZdNB7BASM5nBud5byf/jWgLd10Z1TulR3FDvt4JkbrDdQrSEIF0o7MyeWC9jF02 hLHEdW4jypmGw== From: Alessandro Zucchelli To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Alessandro Zucchelli , Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4] misra: add deviation for MISRA C Rule R11.8. Date: Thu, 9 Jan 2025 11:21:21 +0100 Message-ID: <5b8b143207a5dc0478a500cf2d41017bdb982019.1736417750.git.alessandro.zucchelli@bugseng.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @bugseng.com) X-ZM-MESSAGEID: 1736418119570116600 Content-Type: text/plain; charset="utf-8" Rule 11.8 states as following: "A cast shall not remove any `const' or `volatile' qualification from the type pointed to by a pointer". Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use function, where the parameter needs to not be const because it can be set for write or not. As it was decided a new const-only function will lead to more developer confusion than it's worth, this violation is addressed by deviating the function. All cases of casting away const-ness are accompanied with a comment explaining why it is safe given the other flags passed in; such comment is = used by the deviation in order to match the appropriate function call. No functional change. Signed-off-by: Alessandro Zucchelli Reviewed-by: Stefano Stabellini --- Changes from V3: Edit docs/misra/deviations.rst, according to the feedback received. Rebase against the current staging tree. Changes from V2: The deviation has been documented under docs/misra/deviations.rst. Changes from V1: The deviation has been refined to specify that every instance of casting aw= ay const-ness is accompanied by a comment explaining why it is safe. This comment is a requirement that has been incorporated into the text defi= ning the deviation. --- automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++ docs/misra/deviations.rst | 9 +++++++++ 2 files changed, 15 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/= eclair_analysis/ECLAIR/deviations.ecl index ae25eeb76a..a28eb0ae76 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -393,6 +393,12 @@ Fixing this violation would require to increase code c= omplexity and lower readab -config=3DMC3A2.R11.8,reports+=3D{safe,"any_area(any_loc(any_exp(macro(^co= ntainer_of$))))"} -doc_end =20 +-doc_begin=3D"Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use +function, where the parameter needs to not be const because it can be set = for +write or not" +-config=3DMC3A2.R11.8,reports+=3D{safe,"any_area(any_loc(text(^.*__hvm_cop= y.*HVMCOPY_to_guest doesn't modify.*$)))"} +-doc_end + -doc_begin=3D"This construct is used to check if the type is scalar, and f= or this purpose the use of 0 as a null pointer constant is deliberate." -config=3DMC3A2.R11.9,reports+=3D{deliberate, "any_area(any_loc(any_exp(ma= cro(^__ACCESS_ONCE$))))" } diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 15a993d050..fe0b1e10a2 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -353,6 +353,15 @@ Deviations related to MISRA C:2012 Rules: Fixing this violation would require to increase code complexity and= lower readability. - Tagged as `safe` for ECLAIR. =20 + * - R11.8 + - Violations caused by function __hvm_copy occur when a const void + argument is passed, as the const qualifier is stripped. However, in= such + cases, the function ensures that it does not modify the buffer + referenced by the argument, therefore, this use is deemed safe. Fix= ing + this violation would require to increase code complexity and lower + readability. + - Tagged as `safe` for ECLAIR. + * - R11.9 - __ACCESS_ONCE uses an integer, which happens to be zero, as a compile time check. The typecheck uses a cast. The usage of zero or= other --=20 2.43.0