... ("A `typedef' name shall be a unique identifier"). Much like already
done for guest_intpte_t and guest_l[12]e_t, but limited to shadow/multi.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
These do not add any value to the analysis other than duplicating some reports
in whole-program analysis, as the intermediate linking steps are only used to
build the symbol table.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
overlay_get_nodes_info() is called before fdt_overlay_apply() to extract
target paths from the overlay. This fails for overlays using phandle-based
targeting (target = <&label>) because DTC compiles these as unresolved
fixups (target = <0xffffffff>), causing fdt_overlay_target_offset() to
return -FDT_ERR_BADPHANDLE. Prior to this change users were forced to
manually modify the dtbo (even for hwdom) to switch from target to
target-phandle by manually inspecting also the host DTB.
Introduce overlay_get_target_path() which directly handles the two
targeting cases that occur before fixup resolution:
- target-path: the string property is returned directly.
- target = <&label>: the label is found in the overlay's __fixups__
node, then resolved to a path via the base DTB's __symbols__ node.
Libfdt fdt_for_each_property_offset() violates MISRA R20.7. Despite
libfdt being excluded from the analysis, this causes ECLAIR scan to
report a regression because the violation introduced by a macro is
reported at the call site. Deviate R20.7 for libfdt.h.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
In macros it is common to declare local variables using typeof(param) in order
to ensure that side effects are only evaluated once. A consequence of this is
double textural expansion of the parameter, which can get out of hand very
quickly with nested macros.
In C23, the auto keyword has been repurposed to perform type inference.
A GCC extension, __auto_type, is now available in the new toolchain baseline
and avoids the double textural expansion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block
comment. This is also not an example of commented out code, so shouldn't be
considered a R3.1 violation.
Extend the regex to include git://, and swap hyperlink for URL in the
associated documentation to be more precise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
There is consensus towards using more binary literals in Xen,
so they are enabled both for X86_64 and ARM64.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
MISRA C Rule 17.1 prohibits the use of the features that support
variadic functions. Make the deviation already in place for controlled
use of such features more general, relying on the presence of the
`format' attribute on the function declaration.
Add attributes where missing in order to avoid special-casing
certain functions that use variadic arguments.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Similar to the ARM64 compiler, the same assumptions can be made about
the X86_64 toolchain.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."
This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.
Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.
Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across X86 and ARM platforms
(assuming this file is common for them).
References:
- System V x86_64 ABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove special powerpc check]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro names".
Update ECLAIR configuration to deviate clashes: specify the macros that
should be ignored. Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
forbids conversions between incompatible function pointer types.
The violation occurs at the call site:
smp_call_function(halt_this_cpu, NULL, 0);
where 'halt_this_cpu' with type 'void noreturn (*)(void *)' is passed to
'smp_call_function' expecting function pointer of type 'void (*)(void *)'.
The 'noreturn' attribute does not change the function calling convention
or parameter handling at runtime, making the conversion safe.
For now, configure Eclair to just treat implicit conversions that lose
the "noreturn" attribute on a function 'void (*)(void*)' as safe.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # ECLAIR
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specific build
configurations (when assertions are enabled, i.e., when `NDEBUG' is not
defined). This is due to calls to `__builtin_unreachable()' in the
expansion of the macro `ASSERT_UNREACHABLE()'.
Conversely, in builds where `NDEBUG' is defined (assertions are disabled),
the macro `ASSERT_UNREACHABLE()' expands to an empty construct
(`do { } while (0)'), which does not affect the execution flow. This allows
such functions to return normally in such builds, avoiding unreachable code.
To account for that in specific builds, the `noreturn` property of
`__builtin_unreachable()` is overridden in the ECLAIR configuration to
deviate these violations.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to detect accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The definition of MISRA C Rule 12.2 ("The right hand operand of a shift
operator shall lie in the range zero to one less than the width in bits
of the essential type of the left hand operand") is concerned with the
essential type of an expression, while the C Undefined Behaviour is
related to C standard types, which may be wider but not narrower than
the MISRA C essential type. For this reason, it is safe to consider the
C standard type, rather than the essential type when checking the rule.
To avoid regressions, tag the rule as clean and add it to the
monitored set.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA C Rule 10.1 states:
"Operands shall not be of an inappropriate essential type"
The unary minus operator applied to an unsigned type(s) has
a semantics (wrap around) that is well-defined by the toolchains.
Thus, this operation is deemed safe.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Currently, the URL where the ECLAIR MISRA C scan reports are saved
is hardcoded; making it configurable allows multiple runners and storage
servers to be used without resorting to publishing all artifacts
to the same report server.
Additionally, reports will be accessed publicly by using a proxy,
therefore the address that needs to be printed in GitLab analysis logs
is that of the public url, rather than the location where they are stored.
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove unneeded exports]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".
Add a SAF tag and update the comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.
Generate header guards for hypercall-defs.h
Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.
Update deviations.rst accordingly.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA C Rule 21.6 states that "The Standard Library input/output
functions shall not be used".
Xen does not use the functions provided by the Standard Library,
uses -nostdlib to ensure this.
Xen implements a set of functions that share the same names as their
Standard Library equivalent. The implementation of these functions is
available in source form: if some undefined or unspecified behavior
does arise in the implementation, it falls under the jurisdiction of
other MISRA guidelines.
Update ECLAIR configuration to deviate violations of the rule,
tag it as clean and add it to the monitored set.
Updated docs/misra/deviations.rst accordingly.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common and
apply to all architectures. There's no need for arm64 to give them a second
time.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
... in preparation for changing how they're implemented.
Update the MISRA deviations with the new path.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The Eclair runners in GitlabCI have been update. This service is now
included, and redefining results in an error.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The use of "legitimately" mixes the concepts of "it was designed to do this"
and "it was correct to do this".
The latter in particular can go stale. "intended" is a better way of phrasing
this.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
While activating verbose logging simplifies debugging, this causes
GitLab logs to be truncated, preventing the links to the ECLAIR
analysis database to be shown.
No functional change.
Fixes: c4392ec832 ("automation: Add ECLAIR utilities and settings")
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The Xen configurations for the ARM64 and X86_64 ECLAIR analyses
is currently held in fixed files under
'automation/eclair_analysis/xen_{arm,x86}_config'. The values
of the configuration options there are susceptible to going stale
due to configuration option changes.
To enhance maintainability, the configuration under analysis is
derived from the respective architecture's defconfig, with suitable
changes added via EXTRA_XEN_CONFIG.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This ought to have been part of the original patch, so as to avoid breaking
CI.
Fixes: 31c0d6fdf4 ("xen/bsearch: Split out of lib.h into it's own header")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
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 <alessandro.zucchelli@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reformat the list of GNU extensions and non-standard tokens used by Xen
in the ECLAIR configuration to make it easier to review any changes to it.
The extension "ext_missing_varargs_arg", which captures the GNU extension that
allows variadic functions and macros not to require at least one named parameter
before C23 has been renamed to "ext_c_missing_varargs_arg" in the current version
of ECLAIR used in CI, therefore this resolves regressions on MISRA C Rule 1.1:
"The program shall contain no violations of the standard C syntax and constraints,
and shall not exceed the implementation's translation limits."
As a result, Rule 1.1 now has no violations and is tagged as such.
Remove two unused configurations, that were already commented out.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Fixes: 631f535a3d ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Updating the Eclair runner has had knock-on effects with previously-clean
rules now flagging violations:
- x86: Rule 1.1, 1940 violations
- ARM64: Rule 1.1, 725 violations, Rule 2.1, 255 violations
Fixes: 631f535a3d ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
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>
Eclair complains that fw_unreserved_regions() can't see it's declaration.
Include <asm/setup.h> to address this.
This makes Misra Rule 8.4 clean on ARM, so tag it as such.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Eclair reports a violation of MISRA Rule 5.3.
get_stub() has a local ptr variable which genuinely shadows x86_emul_rmw()'s
parameter of the same name. The logic is correct, so the easiest fix is to
rename one of variables.
With this addressed, Rule 5.3 is clean, so mark it as such.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Right now, the non-compat declaration and definition of do_multicall()
differing types for the nr_calls parameter.
This is a MISRA rule 8.3 violation, but it's also time-bomb waiting for the
first 128bit architecture (RISC-V looks as if it might get there first).
Worse, the type chosen here has a side effect of truncating the guest
parameter, because Xen still doesn't have a clean hypercall ABI definition.
Switch uniformly to using unsigned long.
This addresses the MISRA violation, and while it is a guest-visible ABI
change, it's only in the corner case where the guest kernel passed a
bogus-but-correct-when-truncated value. I can't find any any users of
mutilcall which pass a bad size to begin with, so this should have no
practical effect on guests.
In fact, this brings the behaviour of multicalls more in line with the header
description of how it behaves.
With this fix, Xen is now fully clean to Rule 8.3, so mark it so.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tag MISRA C:2012 Rule 16.3 as clean for both architectures:
new violations will cause a failure of the CI/CD pipeline.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Add Rule 11.2 and Rule 18.1 to the monitored set.
Tag Rule 7.3 as clean.
Tag Rule 11.2 and Rule 20.7 as clean only for arm.
Rule 2.2, Rule 9.5 and Directive 4.12 are not accepted: do not enable
them and do not tag them as clean. Same for D4.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Update ECLAIR configuration to consider Rule 13.6 as clean:
new violations of this rule will cause a failure of the CI pipeline.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add deviation 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").
This deviation suppresses the violation arising from autogenerated file
xen/include/generated/autoconf.h
No functional change.
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters
shall be enclosed in parentheses".
The files imported from the gnu-efi package are already deviated, yet
the macro NextMemoryDescriptor is used in non-excluded code, so a further
deviation is needed to exclude also any expansion of the macro.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA C:2012 Rule 20.7 states that "Expressions resulting from the
expansion of macro parameters shall be enclosed in parentheses".
The rational of the rule is that if a macro argument expands to an
expression, there may be problems related to operator precedence, e.g.,
define M(A, B) A * B
M(1+1, 2+2) will expand to: 1+1 * 2+2
Update ECLAIR configuration to tag as 'safe' the expansions of macro
arguments surrounded tokens '{', '}' and ';', since in their presence
problems related to operator precedence can not occur.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA C Rule 18.2 states: "Subtraction between pointers shall
only be applied to pointers that address elements of the same array".
Subtractions between pointer where at least one symbol is a
symbol defined by the linker are safe and thus deviated, because
the compiler cannot exploit the undefined behaviour that would
arise from violating the rules in this case.
To create an ECLAIR configuration that contains the list of
linker-defined symbols, the script "linker-symbols.sh" is used
after a build of xen (without static analysis) is performed.
The generated file "linker_symbols.ecl" is then used as part of the
static analysis configuration.
Additional changes to the ECLAIR integration are:
- perform a build of xen without static analysis during prepare.sh
- run the scripts to generated ECL configuration during the prepare.sh,
rather than analysis.sh
- export ECLAIR_PROJECT_ROOT earlier, to allow such generation
Additionally, the macro page_to_mfn performs a subtraction that is safe,
so its uses are deviated.
No functional changes.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Prior to bd1664db7b ("xen/bitops: Introduce a multiple_bits_set() helper")
the definition of {COMPILE,RUNTIME}_CHECK was fully compliant with respect
to MISRA C Rule 20.7:
"Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses."
However, to allow testing function-like macros, parentheses on the "fn"
parameter were removed and thus new violations of the rule have been
introduced. Given the usefulness of this functionality,
it is deemed ok to deviate these two macros for this rule, because
their scope of (direct) usage is limited to just the file where they
are defined, and the possibility of misuses is unlikely.
No functional change.
Fixes: bd1664db7b ("xen/bitops: Introduce a multiple_bits_set() helper")
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich
Nicola Vetrini
Michal Orzel
Andrew Cooper
Dmytro Prokopchuk1
Stefano Stabellini
Federico Serafini
Roger Pau Monne
Alessandro Zucchelli