From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
consulting@bugseng.com, "Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Bertrand Marquis" <Bertrand.Marquis@arm.com>,
"Michal Orzel" <michal.orzel@amd.com>
Subject: Re: Misra R17.1 in Xen
Date: Tue, 30 Dec 2025 19:28:35 +0100 [thread overview]
Message-ID: <6d065af376df5527dc6a8f0a47054d85@bugseng.com> (raw)
In-Reply-To: <d87f8fc638192656fa2a44eb9eff7801@bugseng.com>
On 2025-12-30 18:34, Nicola Vetrini wrote:
> On 2025-12-30 18:05, Andrew Cooper wrote:
>> Hello,
>>
>> The x86_64-allcode run highlights one new violation of R17.1,
>> vmcoreinfo_append_str(). In writing this email, I've found another in
>> debugtrace_printk() meaning that we're missing some options in the
>> -allcode configuration.
>>
>> In deviations.ecl we have:
>>
>> -doc_begin="printf()-like functions are allowed to use the variadic
>> features provided by stdarg.h."
>> -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"}
>> -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"}
>> -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
>> -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
>> -config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
>> -config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
>> -doc_end
>>
>>
>> First, we have no printf() so that row should be removed.
>>
>
> I think it was for other variants of printf that are present in Xen
> (e.g. vsnprintf). Perhaps it could be restricted a bit to be more
> explicit.
>
>> But, more importantly this is safe if and only if the function
>> declaration uses __attribute__((__format__(printf, ...))) to cause the
>> compiler to perform format typechecking.
>>
>> Is it possible to encode this attribute requirement in the Eclair
>> expression, so that e.g. accidentally dropping the attribute causes a
>> violation to be reported? This would also be rather safer than
>> assuming
>> that any prefix on printk() is safe.
>>
>
> Well, the UBs associated to that rule (to varargs in general) go beyond
> the formatting issues, but checking that the function decl has the
> attribute is a good suggestion to harden these deviations. I'll make
> some experiments and report back on this thread.
Currently it is possible to match on the presence of the attribute
"format", not on its arguments. Since "printf" is the only archetype
used with "format" I don't think this is a big issue currently, but I'll
let you be the judge on that.
>
>> Thanks,
>>
>> ~Andrew
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
next prev parent reply other threads:[~2025-12-30 18:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 17:05 Misra R17.1 in Xen Andrew Cooper
2025-12-30 17:34 ` Nicola Vetrini
2025-12-30 18:28 ` Nicola Vetrini [this message]
2025-12-30 18:34 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d065af376df5527dc6a8f0a47054d85@bugseng.com \
--to=nicola.vetrini@bugseng.com \
--cc=Bertrand.Marquis@arm.com \
--cc=andrew.cooper3@citrix.com \
--cc=consulting@bugseng.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.