All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/7] x86/dom0: placate GCC 12 compile-time errors with UBSAN and PVH_GUEST
Date: Fri, 14 Mar 2025 09:27:26 +0100	[thread overview]
Message-ID: <Z9PobmG8lDy-oscG@macbook.local> (raw)
In-Reply-To: <eaf90340-929c-4c89-99cf-0383918e9d5a@suse.com>

On Fri, Mar 14, 2025 at 09:10:59AM +0100, Jan Beulich wrote:
> On 13.03.2025 16:30, Roger Pau Monne wrote:
> > When building Xen with GCC 12 with UBSAN and PVH_GUEST both enabled the
> > compiler emits the following errors:
> > 
> > arch/x86/setup.c: In function '__start_xen':
> > arch/x86/setup.c:1504:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
> >  1504 |             end = consider_modules(s, e, reloc_size + mask,
> >       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >  1505 |                                    bi->mods, bi->nr_modules, -1);
> >       |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > arch/x86/setup.c:1504:19: note: referencing argument 4 of type 'const struct boot_module[0]'
> > arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
> >   686 | static uint64_t __init consider_modules(
> >       |                        ^~~~~~~~~~~~~~~~
> > arch/x86/setup.c:1535:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
> >  1535 |             end = consider_modules(s, e, size, bi->mods,
> >       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >  1536 |                                    bi->nr_modules + relocated, j);
> >       |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > arch/x86/setup.c:1535:19: note: referencing argument 4 of type 'const struct boot_module[0]'
> > arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
> >   686 | static uint64_t __init consider_modules(
> >       |                        ^~~~~~~~~~~~~~~~
> > 
> > This seems to be the result of some function manipulation done by UBSAN
> > triggering GCC stringops related errors.  Placate the errors by declaring
> > the function parameter as `const struct *boot_module` instead of `const
> > struct boot_module[]`.
> > 
> > Note that GCC 13 seems to be fixed, and doesn't trigger the error when
> > using `[]`.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> >  xen/arch/x86/setup.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 4a32d8491186..bde5d75ea6ab 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -684,7 +684,7 @@ static void __init noinline move_xen(void)
> >  #undef BOOTSTRAP_MAP_LIMIT
> >  
> >  static uint64_t __init consider_modules(
> > -    uint64_t s, uint64_t e, uint32_t size, const struct boot_module mods[],
> > +    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
> >      unsigned int nr_mods, unsigned int this_mod)
> >  {
> >      unsigned int i;
> 
> While I'm okay-ish with the change, how are we going to make sure it won't be
> re-introduced? Or something similar be introduced elsewhere?

I'm afraid I don't have a good response, as I don't even know exactly
why the error triggers.  We will rely on the CI to start doing
randconfig builds with UBSAN enabled (see patch 7/7).

Thanks, Roger.


  reply	other threads:[~2025-03-14  8:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 15:30 [PATCH 0/7] x86/ubsan: fix ubsan on clang + code fixes Roger Pau Monne
2025-03-13 15:30 ` [PATCH 1/7] xen/ubsan: provide helper for clang's -fsanitize=function Roger Pau Monne
2025-03-13 17:18   ` Andrew Cooper
2025-03-13 15:30 ` [PATCH 2/7] x86/wait: prevent duplicated assembly labels Roger Pau Monne
2025-03-13 19:07   ` Andrew Cooper
2025-03-14  8:24   ` Jan Beulich
2025-03-14  8:30     ` Roger Pau Monné
2025-03-14  8:44       ` Jan Beulich
2025-03-14  9:05         ` Andrew Cooper
2025-03-14  9:13           ` Jan Beulich
2025-03-14 10:12             ` Roger Pau Monné
2025-03-14 11:17               ` Jan Beulich
2025-03-14 11:20               ` Andrew Cooper
2025-03-14  9:06         ` Roger Pau Monné
2025-03-14  9:15           ` Jan Beulich
2025-03-13 15:30 ` [PATCH 3/7] x86/dom0: placate GCC 12 compile-time errors with UBSAN and PVH_GUEST Roger Pau Monne
2025-03-13 19:35   ` Andrew Cooper
2025-03-14  8:10   ` Jan Beulich
2025-03-14  8:27     ` Roger Pau Monné [this message]
2025-03-14  8:33       ` Jan Beulich
2025-03-14  9:10         ` Roger Pau Monné
2025-03-13 15:30 ` [PATCH 4/7] xen/ubsan: expand pointer overflow message printing Roger Pau Monne
2025-03-13 17:22   ` Andrew Cooper
2025-03-13 15:30 ` [PATCH 5/7] x86/ioremap: prevent additions against the NULL pointer Roger Pau Monne
2025-03-13 17:21   ` Andrew Cooper
2025-03-14  8:43     ` Roger Pau Monné
2025-03-14 11:25       ` Andrew Cooper
2025-03-13 15:30 ` [PATCH 6/7] x86/vga: fix mapping of the VGA text buffer Roger Pau Monne
2025-03-13 19:39   ` Andrew Cooper
2025-03-14 10:39     ` Roger Pau Monné
2025-03-14 11:23       ` Jan Beulich
2025-03-14 11:58         ` Roger Pau Monné
2025-03-13 15:30 ` [PATCH 7/7] kconfig/randconfig: enable UBSAN for randconfig Roger Pau Monne

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=Z9PobmG8lDy-oscG@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --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.