Commit Graph
16 Commits
Author SHA1 Message Date
Dmytro Prokopchuk1 2c5b7446a7 misra: address violation of MISRA C Rule 10.1
Rule 10.1: Operands shall not be of an
inappropriate essential type

The following are non-compliant:
- boolean used as a numeric value.

The result of the '__isleap' macro is a boolean.
Suppress analyser tool finding.

The result of 'NOW() > timeout' is a boolean,
which is compared to a numeric value. Fix this.
Regression was introdiced by commit:
be7f047e08 (xen/arm: smmuv3: Replace linux functions with xen functions.)

Remove pointless cast '(const unsigned short int *)'.
The source array and the destination pointer are both of the same type.

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
2025-07-16 17:42:22 -07:00
Volodymyr Babchuk be2a6a1096 xen: common: add ability to enable stack protector
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This patch
makes general preparations to enable this feature on different
supported architectures:

 - Added CONFIG_HAS_STACK_PROTECTOR option so each architecture
   can enable this feature individually
 - Added user-selectable CONFIG_STACK_PROTECTOR option
 - Implemented code that sets up random stack canary and a basic
   handler for stack protector failures

Stack guard value is initialized in two phases:

1. Pre-defined randomly-selected value.

2. Own implementation of linear congruent random number generator. It
relies on get_cycles() being available very early. If get_cycles()
returns zero, it would leave pre-defined value from the previous step.

boot_stack_chk_guard_setup() is declared as always_inline to ensure
that it will not trigger stack protector by itself. And of course,
caller should ensure that stack protection code will not be reached
later. It is possible to call the same function from an ASM code by
introducing simple trampoline in stack-protector.c, but right now
there is no use case for such trampoline.

As __stack_chk_fail() is not called by Xen source code directly, and
only called by compiler-generated code, it does not needed to be
declared separately. So we need separate MISRA deviation for it.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
2025-04-14 13:07:12 +02:00
Stefano Stabellini 37d6d8daba xen/x86: resolve the last 3 MISRA R16.6 violations
MISRA R16.6 states that "Every switch statement shall have at least two
switch-clauses". There are only 3 violations left on x86 (zero on ARM).

One of them is only a violation depending on the kconfig configuration.
So deviate it instead with a SAF comment.

Two of them are deliberate to enable future additions. Deviate them as
such.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
2025-02-20 13:32:46 -08:00
Alessandro Zucchelli 631f535a3d xen: update ECLAIR service identifiers from MC3R1 to MC3A2.
Rename all instances of ECLAIR MISRA C:2012 service identifiers,
identified by the prefix MC3R1, to use the prefix MC3A2, which
refers to MISRA C:2012 Amendment 2 guidelines.

This update is motivated by the need to upgrade ECLAIR GitLab runners
that use the new naming scheme for MISRA C:2012 Amendment 2 guidelines.

Changes to the docs/misra directory are needed in order to keep
comment-based deviation up to date.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-12-17 13:04:48 +00:00
Simone Ballarin 89719f57cc misra: add deviations for direct inclusion guards
Add deviation comments to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").

Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere).

This patch adds deviation comments using the format specified
in docs/misra/safe.json for headers with just the direct
inclusion guard before the inclusion guard since they are
safe and not supposed to comply with the directive.

Note that with SAF-10-safe in place, failures to have proper guards later
in the header files will not be reported

Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-07-30 11:55:09 +02:00
Simone Ballarin 79b9c0cdd8 misra: modify deviations for empty and generated headers
This patch modifies deviations for Directive 4.10:
"Precautions shall be taken in order to prevent the contents of
a header file being included more than once"

This patch avoids the file-based deviation for empty headers, and
replaces it with a comment-based one using the format specified in
docs/misra/safe.json.

Generated headers are not generally safe against multi-inclusions,
whether a header is safe depends on the nature of the generated code
in the header. For that reason, this patch drops the deviation for
generated headers.

Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
2024-07-30 11:54:42 +02:00
Simone Ballarin d2ff674a9c misra: add deviation for headers that explicitly avoid guards
Some headers, under specific circumstances (documented in a comment at
the beginning of the file), explicitly do not have strict inclusion
guards: the caller is responsible for including them correctly.

These files are not supposed to comply with Directive 4.10:
"Precautions shall be taken in order to prevent the contents of a header
file being included more than once"

This patch adds deviation cooments for headers that avoid guards.

Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-07-30 11:54:11 +02:00
Nicola Vetrini 0dca0f2b9a automation/eclair: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".

The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
2024-06-27 13:45:18 +02:00
Nicola Vetrini 0a5b2ca32c x86/domain: deviate violation of MISRA C Rule 20.12
MISRA C Rule 20.12 states: "A macro parameter used as an operand to
the # or ## operators, which is itself subject to further macro replacement,
shall only be used as an operand to these operators".

In this case, builds where CONFIG_COMPAT=y the fpu_ctxt
macro is used both as a regular macro argument and as an operand for
stringification in the expansion of CHECK_FIELD_.
This is deviated using a SAF-x-safe comment.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
2024-06-10 10:34:05 +02:00
Nicola Vetrini 1fc166d6cd xen/domain: deviate MISRA C Rule 16.2 violation
MISRA C Rule 16.2 states:
"A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement".

The PROGRESS_VCPU local helper specifies a case that is directly
inside the compound statement of a for loop, hence violating the rule.
To avoid this, the construct is deviated with a text-based deviation.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
2024-04-22 15:11:38 +02:00
Simone Ballarin 402c2d3e66 MISRA C Rule 17.1 states: "The features of `<stdarg.h>' shall not be used"
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.

Functions hypercall_create_continuation and hypercall_xlat_continuation
are internal helper functions made to break long running hypercalls into
multiple calls. They take a variable number of arguments depending on the
original hypercall they are trying to continue.

Add SAF deviations for the aforementioned functions.

Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-04-05 11:15:47 -07:00
Nicola Vetrini d2686bf964 xen/compiler: deviate the inline macro for MISRA C Rule 20.4
Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".

Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
functions end up in the correct section while minimizing churn and
has a positive impact on the overall safety. See [1] for additional
context on the motivation of this deviation.

No functional change.

[1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
2024-03-14 13:54:14 +01:00
Nicola Vetrini ee409f36b6 xen/types: address Rule 10.1 for DECLARE_BITMAP use
Given its use in the declaration
'DECLARE_BITMAP(features, IOMMU_FEAT_count)' the argument
'bits' has essential type 'enum iommu_feature', which is not
allowed by the Rule as an operand to the addition operator
in macro 'BITS_TO_LONGS'.

This construct is deviated with a deviation comment.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2023-11-17 18:04:40 -08:00
Nicola Vetrini 5a415ef2b2 xen: apply deviation for Rule 8.4 (asm-only definitions)
As stated in 'docs/misra/rules.rst' the functions that are used only by
asm modules do not need to conform to MISRA C:2012 Rule 8.4.
The deviations are carried out with a SAF comment.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
2023-09-07 09:23:50 +02:00
Luca Fancellu bc19af0bd4 xen: Justify linker script defined symbols in include/xen/kernel.h
Eclair and Coverity found violation of the MISRA rule 8.6 for the
symbols _start, _end, start, _stext, _etext, _srodata, _erodata,
_sinittext, _einittext which are declared in
xen/include/xen/kernel.h.
All those symbols are defined by the liker script so we can deviate
from the rule 8.6 for these cases.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
2022-12-12 14:19:20 -08:00
Luca Fancellu b4465e73b1 xen/scripts: add xen-analysis.py for coverity and eclair analysis
Add new script for coverity/eclair analysis tool that will enable
the procedure to suppress findings when these tool are used.
The procedure is documented in docs/misra/documenting-violations.rst
and the script is documented in docs/misra/xen-static-analysis.rst.

Add in docs/misra/ the files safe.json and
false-positive-{coverity,eclair}.json that are JSON files containing
the data structures for the justifications, they are used by the
analysis script to link the Xen tags to the proprietary tool comment.

Add docs/misra/documenting-violations.rst to explain how to add
justifications.

Add docs/misra/xen-static-analysis.rst to explain how to use the
script to analyse Xen.

Add analysis artifacts files to .gitignore.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
2022-12-12 14:19:04 -08:00