[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Misra R17.1 in Xen
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- Date: Tue, 30 Dec 2025 18:34:36 +0100
- Arc-authentication-results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
- Arc-message-signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767116077; h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To: References:Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=VD9yZ49TX3PZn18QGlS86Yttz4SfYHRGAunuDNXFAzI=; b=18KVQcOnF9WWgEo9cU+IKBbHOAgsaod+NKJpDVx6RL4gHv23Wbjp5+ty2J0LB1GIwgpn l+LvIs/kZqcSu6uvFtpsUYQbsFQ57QeQAVDWnbfZC7yMWETNcG6bT59mMYM+0HWcNdLgf z76ta0zcRWVpj5LMUCiZNJLWaatPQpugjMr6CYZ23Mx5JvkJGXyKdTG0tD7SZgmt9LV8/ FSDFM2Mbd1r+iTVbjn0ea6yl3XyCXS2efzgSTcNlxMFryX3gx/rYtbPsBKPOzM00MRqNq o1mGBCVXV6h5MedTXzopKlTt2xLrAA3D9bPQWqHymLj3nh+oNT37vROMZUZq0HGu+AxK1 kYlXMNEfHW7C3+5IGhV9EeqTRHX8RC2gP0R4M0vvIaCctUtgm9rZQ3snqjyDxHwgj0p6o gK6Vd5j22uwQRWjcAnSF3Pcs2tHSwgdVetSkUOayU2Gp4EANF7OUAsbBaMGLwAs7pjGm6 /LBUM9xiM7iRMJHeaDbJ/snQ9AmiuT04b/TvsBlIujN4aXfdBFRhCsE+FKbR6pOrK74vi rYAW6sTodFWqHL8k5VX0AELTjLuxBHuXHHVU4k55M4Hdm4nGF7qyfH+XPgOoEe8qvuxts oBdJCJmFbkw9fRVC95cMTkn6bS2XM9w2DwRLYE12W8wAUXjlTAWqfsPtmmN75DY=
- Arc-seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1767116077; b=dH2f7C13RYHKtVxI4yZrWfWgypzR0KMXNROahmnwuaQCGpbl3oOvI5Dx3hGimfeqPDc+ 7eILRGiLWdAs8f8x9PQc4PySB54nslVzjK4N4c4DB9KoixR2icbZZY0bGljYTQCSuuAgV bKrrXEgCGHvTxFfZTZDGqCFjzI0Q2cGuqn7+SOxM0u5pDzKroW+KF9WZFcPOlRcbOLWgb WhbOGeql+IKo3kyEpITYuyeBdV9XZzZT4+O1KplI8GElSRhCP8qGMTiT66cDRR13uys29 Ii0iEZllClNDOSnkekRnuAufWQCHJfdUIHJepkSa73tgG1voq/49zN3VDyPX+HIrN4p+X zri2pIv8ZOZm+jZDFNVY+MxcLxPpm945jbodv62BCT3RKw1NvXQ1nDN1YpfKIMa/bF4l6 9W0ngcQfcdtaxCXq6V8wBM7MDGhqtNqo582PluBfuyoCctI1B2LZADbo/c42HLM3sWf1d mpIwqXfTjXluyE/pfp5JOpOGag/6gAlaXkayHPSUfgzL2iXatJboGDN5St72P5I70vgeW Wks4oL6heT9eRTk/JZtetXB+AYRNi869MmpxTqMMqFp9foT0QWV4N2aQAOGJM2SvxJySQ qBYSwlw5FHoPUC1b3GDGj0QyZ1EOwZkBaPr6Vd+GtQRCuxhfRHm3LQwNOjpy6gk=
- Authentication-results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
- Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, consulting@xxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
- Delivery-date: Tue, 30 Dec 2025 17:34:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
Thanks,
~Andrew
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
|