Messages in this thread | | | Date | Mon, 8 Jun 2020 15:51:50 +0100 | From | Will Deacon <> | Subject | Re: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof |
| |
Hey Nick,
On Tue, Jun 02, 2020 at 11:46:31AM -0700, Nick Desaulniers wrote: > On Mon, Jun 1, 2020 at 5:03 PM Kaneda, Erik <erik.kaneda@intel.com> wrote: > > > Will reported UBSAN warnings: > > > UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37 > > > UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6 > > > > > > Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We > > > can avoid this by using the compiler builtin, __builtin_offsetof. > > > > I'll take a look at this tomorrow > > > > > > The non-kernel runtime of UBSAN would print: > > > runtime error: member access within null pointer of type for this macro. > > > > actypes.h is owned by ACPICA so we typically do not allow compiler-specific > > extensions because the code is intended to be compiled using the C99 standard > > without compiler extensions. We could allow this sort of thing in a Linux-specific > > header file like include/acpi/platform/aclinux.h but I'll take a look at the error as well.. > > If I'm not allowed to touch that header, it looks like I can include > <linux/stddef.h> (rather than my host's <stddef.h>) to get a > definition of `offsetof` thats implemented in terms of > `__builtin_offsetof`. I should be able to use that to replace uses of > ACPI_OFFSET. Are any of these off limits?
It's not so much about not being allowed to touch the header, but rather that the kernel imports the code from a different project:
https://acpica.org/community
> $ grep -rn ACPI_OFFSET > arch/arm64/include/asm/acpi.h:34:#define ACPI_MADT_GICC_MIN_LENGTH > ACPI_OFFSET( \ > arch/arm64/include/asm/acpi.h:41:#define ACPI_MADT_GICC_SPE > (ACPI_OFFSET(struct acpi_madt_generic_interrupt, \
I'm happy to take patches to the stuff under arch/arm64/, fwiw.
Will
| |