From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH] x86/hvmloader: fix usage of NULL with cpuid_count()
Date: Thu, 24 Apr 2025 16:33:48 +0200 [thread overview]
Message-ID: <aApLzKSC5wnLeShs@macbook.lan> (raw)
In-Reply-To: <72b6e9b8-8f6a-4495-ac1c-9df5822067a8@citrix.com>
On Thu, Apr 24, 2025 at 03:21:05PM +0100, Andrew Cooper wrote:
> On 24/04/2025 1:58 pm, Roger Pau Monne wrote:
> > The commit that added support for retrieving the APIC IDs from the APs
> > introduced several usages of cpuid() with NULL parameters, which is not
> > handled by the underlying implementation. For GCC I expect this results in
> > writes to the physical address at 0, however for Clang the generated code
> > in smp.o is:
>
> Oh lovely. I guess we need full VM testing for the Clang builds too.
>
> > tools/firmware/hvmloader/smp.o: file format elf32-i386
> >
> > Disassembly of section .text:
> >
> > 00000000 <smp_initialise>:
> > 0: 55 pushl %ebp
> > 1: 89 e5 movl %esp, %ebp
> > 3: 53 pushl %ebx
> > 4: 31 c0 xorl %eax, %eax
> > 6: 31 c9 xorl %ecx, %ecx
> > 8: 0f a2 cpuid
>
> I get the hint that this is the whole file? But you don't say that
> explicitly.
Yeah, realized later while reading the message myself. This is indeed
the whole file.
> > Showing the usage of a NULL pointer results in undefined behavior, and
> > clang refusing to generate further code after it.
> >
> > Fix by using a temporary variable in cpuid_count() in place for any NULL
> > parameter.
> >
> > Fixes: 9ad0db58c7e2 ('tools/hvmloader: Retrieve APIC IDs from the APs themselves')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Could also be fixed by using the temporary variable in the call sites,
> > however that's more code in the call sites at the expense of less checking.
> > I don't think the extra NULL check logic in cpuid_count() is that bad.
> >
> > Overall the solution proposed in this patch is safer going forward, as it
> > prevent issues like this from being introduced in the first place.
> > ---
> > tools/firmware/hvmloader/util.h | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> > index 644450c51ceb..765a013ddd9e 100644
> > --- a/tools/firmware/hvmloader/util.h
> > +++ b/tools/firmware/hvmloader/util.h
> > @@ -190,6 +190,17 @@ static inline void cpuid_count(
> > uint32_t *ecx,
> > uint32_t *edx)
> > {
> > + uint32_t tmp;
> > +
> > + if ( !eax )
> > + eax = &tmp;
> > + if ( !ebx )
> > + ebx = &tmp;
> > + if ( !ecx )
> > + ecx = &tmp;
> > + if ( !edx )
> > + edx = &tmp;
> > +
>
> Personally I dislike this pattern, and some of that is definitely PTSD
> from Xen's original hvm_cpuid() function.
>
> hvmloader is a small enough codebase that I don't think it matters
> either way.
>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>, preferably with
> clarity over the disassembly.
I've adjusted to:
"""
For GCC I expect this results in writes to the physical address at 0,
however for Clang the generated code in smp.o for the whole file is:
tools/firmware/hvmloader/smp.o: file format elf32-i386
...
"""
Thanks, Roger.
next prev parent reply other threads:[~2025-04-24 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 12:58 [PATCH] x86/hvmloader: fix usage of NULL with cpuid_count() Roger Pau Monne
2025-04-24 14:21 ` Andrew Cooper
2025-04-24 14:33 ` Roger Pau Monné [this message]
2025-04-25 12:23 ` Alejandro Vallejo
2025-04-25 12:44 ` Roger Pau Monné
2025-04-25 12:54 ` Alejandro Vallejo
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=aApLzKSC5wnLeShs@macbook.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--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.