[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/hvmloader: fix usage of NULL with cpuid_count()
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@xxxxxxxxxx> > > --- > > 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@xxxxxxxxxx>, 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.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |