RE: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof

From: Kaneda, Erik
Date: Mon Jun 08 2020 - 20:07:02 EST




> -----Original Message-----
> From: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> Sent: Tuesday, June 2, 2020 11:47 AM
> To: Kaneda, Erik <erik.kaneda@xxxxxxxxx>
> Cc: Moore, Robert <robert.moore@xxxxxxxxx>; Wysocki, Rafael J
> <rafael.j.wysocki@xxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; Ard
> Biesheuvel <ardb@xxxxxxxxxx>; dvyukov@xxxxxxxxxx; glider@xxxxxxxxxx;
> guohanjun@xxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; lorenzo.pieralisi@xxxxxxx;
> mark.rutland@xxxxxxx; pcc@xxxxxxxxxx; rjw@xxxxxxxxxxxxx;
> will@xxxxxxxxxx; stable@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxx
> Subject: Re: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof
>
> On Mon, Jun 1, 2020 at 5:03 PM Kaneda, Erik <erik.kaneda@xxxxxxxxx>
> wrote:
> >
> >
> > Hi,
> >
> > > 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..
>
Hi,

> 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

Why not use your host's stddef.h?

> `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?

Yes, the idea is to define ACPI_OFFSET in a way that you want so that we don't touch the uses below.

Erik
>
> $ 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, \
> include/acpi/actbl.h:376:#define ACPI_FADT_OFFSET(f) (u16)
> ACPI_OFFSET (struct acpi_table_fadt, f)
> drivers/acpi/acpica/acresrc.h:84:#define ACPI_RS_OFFSET(f)
> (u8) ACPI_OFFSET (struct acpi_resource,f)
> drivers/acpi/acpica/acresrc.h:85:#define AML_OFFSET(f)
> (u8) ACPI_OFFSET (union aml_resource,f)
> drivers/acpi/acpica/acinterp.h:17:#define ACPI_EXD_OFFSET(f)
> (u8) ACPI_OFFSET (union acpi_operand_object,f)
> drivers/acpi/acpica/acinterp.h:18:#define ACPI_EXD_NSOFFSET(f)
> (u8) ACPI_OFFSET (struct acpi_namespace_node,f)
> drivers/acpi/acpica/rsdumpinfo.c:16:#define ACPI_RSD_OFFSET(f)
> (u8) ACPI_OFFSET (union acpi_resource_data,f)
> drivers/acpi/acpica/rsdumpinfo.c:17:#define ACPI_PRT_OFFSET(f)
> (u8) ACPI_OFFSET (struct acpi_pci_routing_table,f)
>
> --
> Thanks,
> ~Nick Desaulniers