The R11.1 safe cast only matched void noreturn (*)(void *). Accept a
conversion where noreturn is omitted and the signature is otherwise
compatible. canonical() covers typeof destinations, and
compatible_deep_unqualified keeps the parameter and return types aligned.
Discarding noreturn does not change the calling convention. Code after
the call is unreachable when every possible callee is noreturn. Leaving
that code in place is a tolerated Rule 2.1 violation. The full rationale
is in docs/misra/deviations.rst.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # automation/eclair_analysis/.*
Acked-by: Jan Beulich <jbeulich@suse.com>
The hide pattern .xen-syms.[013] leaves pass 2 visible. On x86
LAST_LINKING_PASS is 2, so that is the final link. On Arm
LAST_LINKING_PASS is 3 and the final image is .xen-syms.3. Pass 2 is
usually only a symlink, so Eclair saw no program link and reported every
translation unit as unreachable.
During analysis preparation, read LAST_LINKING_PASS from the architecture
makefile and the pass numbers from the foreach list in
xen/scripts/Makefile.link. Hide every pass except that one. An earlier
pass that is a real link stays hidden. The generator runs from
generate_ecl.sh, together with the other ECLAIR configuration scripts.
Fixes: a401b5c9dc ("Eclair: re-enable scanning of the (almost) final linking step")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The file scoping restrictions were spelled out in the documentation comment,
but not enforced by the configuration.
Remove duplicated file tag asm_offsets while at it.
No functional change.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro
names".
Update ECLAIR configuration to deviate identifier and macro name
clashes by specifying the macros that should be ignored.
This includes hypfs_alloc_dyndata(), where the real function takes
an allocation size and the same-named macro is a typed convenience
wrapper that expands calls using sizeof(type).
Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These have been clean for a while already, without being marked so.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
Like x86/HVM's __hvm_copy(), Arm's copy_guest() is used for both to-guest
and from-guest copying. Naturally in the latter case the hypervisor buffer
needs writing to, hence the function parameter cannot be pointer-to-const.
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
The real final binaries are now no longer created by a linker invocation,
but by renaming an intermediate file (each). Arrange for linking pass 2
outputs to be scanned instead, yet continue to exclude the auxiliary
.xen.efi.alt.* binaries.
Fixes: da944a72fd ("x86: split xen-syms/xen.efi linking rules"))
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
What is true for unsigned long is also true for plain/signed long, thus
also taking care of two instances of __x86_return_thunk() being cast to
long.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
BUILD_ERROR() is even stronger a guard than assertions in general, and
ASSERT_UNREACHABLE() (or BUG()) in particular. Deviate it just like those
to allow use for marking unreachable portions of code.
In some cases code being unreachable is dependent upon configuration.
Introduce two variants, as constructs like
if ( IS_ENABLED(CONFIG_...) )
BUILD_ERROR("...");
results in the if() still being reported as unreachable. Sadly these two
new macros introduce a new 20.12 violation each, which hence also needs
deviating.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Build issues may also surface for analysis jobs. Collect intermediate
files (if any) there as well. Include xen/.config too, since it's not
otherwise collected.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
... ("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>
Dmytro Prokopchuk