Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4658134ybg; Mon, 8 Jun 2020 13:33:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9ODj1vWiP4/K+raZC15s55vPwoAlnNZI8QUhh1LwoQAkJ90vX+UobS7bEg0lD5bbz0e8Z X-Received: by 2002:a17:906:6b8a:: with SMTP id l10mr21161588ejr.465.1591648412228; Mon, 08 Jun 2020 13:33:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591648412; cv=none; d=google.com; s=arc-20160816; b=cNG1zhrvZSvjw8BrkxmHToYoqfr3HluKzjlop8JFvhkMdunVYuwloeGxZ6p/cVW6jn S9jJexuCbVIUIOCKDH4xOu97mucUzZVcXaq13pPPtywQ6QUxpqeJu4Uvr3SY2Nxy57G/ +CdTM+GpCr+R3InPRKn53XKUflRlYHEKt4QxqOWrjfrURouNmeYW5iXV0sydGCzlLOPG rdN83DCMECo8PxTkOLQKf/WVvHJddqWBAd0+xO6BkeM2duDaKQsJ8AylN3+DzqHiaOOH s8sQuPBkFQp3lpTHtb2timS+rPrWWmpeAZZOa7H/YYe1NEVUCh4/W5gQ7pCWe6lfqYmJ N1Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9/ePEPr3ygUN4g38F3++3TkPRxfaceUs+kBlSlUSKY0=; b=k6Gwg88zzgAiQ7XgQC/sUEVI5BVjYDvyaH9jP0LGLm6/UqsBNlmlL7L2VCWgkPUQmO 9jeirNgTExN/7o7H4QtSUSuvWDBhXPGYIDvOt7gdxb2A+ujipEeIwDY75d8x0af5ww06 RRIR6fHK2zXkmwsPgkksXus2qJCAG4gYPnSTgheI5PPUH2oYOpfaJ9rNxI4HPZnC8Ucn 8Rp08OLZ3z4rCL6BNJKCJw6PTIvqKYSazKOqhH8IPmkeIs3yAzOdwUXTyfetlmtbpJ4s AQ8cGglL7ggV52ffhm6AE+TshgvejrzHASyEzpmEqmszoFU+RK18WIbWkFSxBQA77+4z GaZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pw8Bxdhl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b10si8980025edr.286.2020.06.08.13.32.55; Mon, 08 Jun 2020 13:33:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pw8Bxdhl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726741AbgFHU35 (ORCPT + 99 others); Mon, 8 Jun 2020 16:29:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726415AbgFHU34 (ORCPT ); Mon, 8 Jun 2020 16:29:56 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5458DC08C5C2 for ; Mon, 8 Jun 2020 13:29:56 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id b7so274575pju.0 for ; Mon, 08 Jun 2020 13:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9/ePEPr3ygUN4g38F3++3TkPRxfaceUs+kBlSlUSKY0=; b=pw8Bxdhl9XS8tPgtRzulSMnEvJeKhw67A+rrpfiRgoNRVcVxkndGIyj1Htofn7jVH4 QQfC8wwV1c2hsbd3F+BArgJJLlVJygelysnZp9v8OWukz4LhpZm+mPNjLH12Rd6OrYqv FEepyuJwLd31BVubTZVtn1FwTiI9AReTM8JynaA0xsEGX3ndHt2r47Zqeq30tgQZ8wVC 8g6XsZLQuN3A2UBO1Vc4xRfN66xu2jdQFy7ZOSpEIlWqwg+LIA2MCYx82el77wcfvMaA K7z7TSrp13wbs0s5jkpBtBoquIhBmNnU+rdDHrJolRI2C6P7l78M4Jbr0MihSflNPFXb +zfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9/ePEPr3ygUN4g38F3++3TkPRxfaceUs+kBlSlUSKY0=; b=a2GHWAOlFEImiQBoDvJPM0zUhQgWPwtxun7ctpjYWcuFf8o+3qBF+bu+e7OHhtPeoy eDbFaaB+FECsp6Hu0RT2hAA+qYFzIfRXgNB8O6Z9oyutohqmhTGSCkqHna1sZCejYdZ4 bDdgp2nfM8kuPWnE+Sx0bSOkuBCP5Xzed/0SnzkS4t49vQ6HGHCfnEOK6dQOhkibP5LZ jFkjsNrS7ssuuH5E45Y4unsJFNNvs+uRh8AQ8CRTILyE2b7skWTn2854o3AgPNbTnS2m hAOiDVIoqGjZOcj7+AgqzL2PU3bkCHyoplM/V2ARyQK9vJ33sF/h3MPlaHDxAX8Ufidy eYhw== X-Gm-Message-State: AOAM531wQteRX9AWP1UWfbwJBNGcVsPvzQk5FtnXlAkyC1EuIKFiXTtN 7X6sZJxVjBaGN/DQQNXI8CXOeqgvP3jCigPFTjl/rg== X-Received: by 2002:a17:90a:e2c4:: with SMTP id fr4mr1046413pjb.32.1591648195517; Mon, 08 Jun 2020 13:29:55 -0700 (PDT) MIME-Version: 1.0 References: <20200601231805.207441-1-ndesaulniers@google.com> <20200608145150.GA7418@willie-the-truck> In-Reply-To: <20200608145150.GA7418@willie-the-truck> From: Nick Desaulniers Date: Mon, 8 Jun 2020 13:29:44 -0700 Message-ID: Subject: Re: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof To: Will Deacon , "Moore, Robert" Cc: "Kaneda, Erik" , "Wysocki, Rafael J" , Len Brown , Ard Biesheuvel , "dvyukov@google.com" , "glider@google.com" , "guohanjun@huawei.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "mark.rutland@arm.com" , "pcc@google.com" , "rjw@rjwysocki.net" , "stable@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "devel@acpica.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 8, 2020 at 7:51 AM Will Deacon wrote: > > 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 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 > > (rather than my host's ) 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. Not really sure how to untangle this. Those two cases under arch/arm64/ are straightforward to fix: ``` diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index b263e239cb59..a45366c3909b 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -31,14 +32,14 @@ * is therefore used to delimit the MADT GICC structure minimum length * appropriately. */ -#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ +#define ACPI_MADT_GICC_MIN_LENGTH offsetof( \ struct acpi_madt_generic_interrupt, efficiency_class) #define BAD_MADT_GICC_ENTRY(entry, end) \ (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ (unsigned long)(entry) + (entry)->header.length > (end)) -#define ACPI_MADT_GICC_SPE (ACPI_OFFSET(struct acpi_madt_generic_interrupt, \ +#define ACPI_MADT_GICC_SPE (offsetof(struct acpi_madt_generic_interrupt, \ spe_interrupt) + sizeof(u16)) /* Basic configuration for ACPI */ ``` But for one of the warnings you reported, as an example: UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37 ``` $ ag ACPI_FADT_V2_SIZE include/acpi/actbl.h 394:#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (minor_revision) + 1) drivers/acpi/acpica/tbfadt.c 459: if (acpi_gbl_FADT.header.length <= ACPI_FADT_V2_SIZE) { $ ag ACPI_FADT_OFFSET ... include/acpi/actbl.h 376:#define ACPI_FADT_OFFSET(f) (u16) ACPI_OFFSET (struct acpi_table_fadt, f) ... ``` So the use of ACPI_FADT_V2_SIZE in drivers/acpi/acpica/tbfadt.c is triggering one of the warnings. ACPI_FADT_V2_SIZE is defined in terms of ACPI_FADT_OFFSET which is defined in terms of ACPI_OFFSET in include/acpi/actbl.h. From the link you posted, include/acpi/actbl.h is from the project under source/include/. Further, drivers/acpi/acpica/tbfadt.c seems to also be from the upstream project under source/components/tables/tbfadt.c. Regardless, the second of the two warnings is definitely fixed by my above diff, so let me rephrase the previous commit message with that diff and resend. -- Thanks, ~Nick Desaulniers