Re: arm64/acpi: NULL dereference reports from UBSAN at boot

From: Will Deacon <will@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: mark.rutland@arm.com, rjw@rjwysocki.net, ndesaulniers@google.com,
	linux-kernel@vger.kernel.org, guohanjun@huawei.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: arm64/acpi: NULL dereference reports from UBSAN at boot
Date: Mon, 1 Jun 2020 08:05:00 +0100	[thread overview]
Message-ID: <20200601070459.GB8601@willie-the-truck> (raw)
In-Reply-To: <20200527134104.GA16115@e121166-lin.cambridge.arm.com>

On Wed, May 27, 2020 at 02:41:04PM +0100, Lorenzo Pieralisi wrote:
> On Tue, May 26, 2020 at 09:21:57PM +0100, Will Deacon wrote:
> > Hi Lorenzo, Hanjun, [+Nick]
> > 
> > On Thu, May 21, 2020 at 06:37:38PM +0100, Lorenzo Pieralisi wrote:
> > > On Thu, May 21, 2020 at 11:09:53AM +0100, Will Deacon wrote:
> > > > Hi folks,
> > > > 
> > > > I just tried booting the arm64 for-kernelci branch under QEMU (version
> > > > 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a
> > > > couple of NULL pointer dereferences reported at boot. I think they're
> > > > both GIC related (log below). I don't see a panic with UBSAN disabled,
> > > > so something's fishy here.
> > > 
> > > May I ask you the QEMU command line please - just to make sure I can
> > > replicate it.
> > 
> > As it turns out, I'm only able to reproduce this when building with Clang,
> > but I don't know whether that's because GCC is missing something of Clang
> > is signalling a false positive. You also don't need all of those whacky
> > fuzzing options enabled.
> > 
> > Anyway, to reproduce:
> > 
> >  $ git checkout for-next/kernelci
> >  $ make ARCH=arm64  CC=clang CROSS_COMPILE=aarch64-linux-gnu- defconfig
> >  <then do a menuconfig and enable UBSAN>
> >  $ make ARCH=arm64  CC=clang CROSS_COMPILE=aarch64-linux-gnu- Image
> > 
> > I throw that at QEMU using:
> > 
> > qemu-system-aarch64 -M virt -machine virtualization=true \
> > 	-machine virt,gic-version=3 \
> > 	-cpu max,sve=off -smp 2 -m 4096 \
> > 	-drive if=pflash,format=raw,file=efi.img,readonly \
> > 	-drive if=pflash,format=raw,file=varstore.img \
> > 	-drive if=virtio,format=raw,file=disk.img \
> > 	-device virtio-scsi-pci,id=scsi0 \
> > 	-device virtio-rng-pci \
> > 	-device virtio-net-pci,netdev=net0 \
> > 	-netdev user,id=net0,hostfwd=tcp::8222-:22 \
> > 	-nographic \
> > 	-kernel ~/work/linux/arch/arm64/boot/Image \
> > 	-append "earlycon root=/dev/vda2"
> > 
> > I built QEMU a while ago according to:
> > 
> > https://mirrors.edge.kernel.org/pub/linux/kernel/people/will/docs/qemu/qemu-arm64-howto.html
> > 
> > and its version 4.2.50 (v4.2.0-779-g4354edb6dcc7).
> > 
> > My clang is version 11.0.1.
> 
> Thanks a lot Will.
> 
> I *think* I was right - it is the ACPI_OFFSET() macro:
> 
> #define ACPI_OFFSET(d, f)  ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> 
> that triggers the warnings (I suspected it because at least in one of
> the warnings I could not see any dereference of any dynamically
> allocated data).

Cheers, Lorenzo.

> Now on what to do with it - thoughts welcome.

Nick -- any idea what to do about the above? The '#define' pasted by
Lorenzo is causing a couple of spurious UBSAN splats when compiling with
clang 11.

Cheers,

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel