From patchwork Fri Oct 23 15:41:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 11853703 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 45AF192C for ; Fri, 23 Oct 2020 15:42:55 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0594420797 for ; Fri, 23 Oct 2020 15:42:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=xen.org header.i=@xen.org header.b="Ex15/X/y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0594420797 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.11092.29413 (Exim 4.92) (envelope-from ) id 1kVzCo-00020v-HM; Fri, 23 Oct 2020 15:42:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 11092.29413; Fri, 23 Oct 2020 15:42:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzCo-00020m-Dh; Fri, 23 Oct 2020 15:42:14 +0000 Received: by outflank-mailman (input) for mailman id 11092; Fri, 23 Oct 2020 15:42:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzCn-000207-Fv for xen-devel@lists.xenproject.org; Fri, 23 Oct 2020 15:42:13 +0000 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb530848-315a-4f24-8da9-04ff76f25cbb; Fri, 23 Oct 2020 15:42:12 +0000 (UTC) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzCl-0006r5-V8; Fri, 23 Oct 2020 15:42:11 +0000 Received: from 54-240-197-235.amazon.com ([54.240.197.235] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVzCl-0007wb-L8; Fri, 23 Oct 2020 15:42:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzCn-000207-Fv for xen-devel@lists.xenproject.org; Fri, 23 Oct 2020 15:42:13 +0000 X-Inumbo-ID: eb530848-315a-4f24-8da9-04ff76f25cbb Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb530848-315a-4f24-8da9-04ff76f25cbb; Fri, 23 Oct 2020 15:42:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=3b+zUC4rUGoRV/bU3U7XTe8hxIwKqKy/A0anE7Xt22g=; b=Ex15/X/yHkm5VcqouUFLOTVy2 GjAr5mN3s7s1NO5KlyhbJPi3JBiSWWOGhwHextGMcqmtQ3f5SmArE0zeJnS0LygZo9+oSD2M3jQcb ECX6CjrkpWg9hBAsPW4DNfNfbmt2qPrknD9dwVZLJ+XUafyOc6C3Q0WD8H8oy2zuwJvZo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzCl-0006r5-V8; Fri, 23 Oct 2020 15:42:11 +0000 Received: from 54-240-197-235.amazon.com ([54.240.197.235] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVzCl-0007wb-L8; Fri, 23 Oct 2020 15:42:11 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Cc: alex.bennee@linaro.org, masami.hiramatsu@linaro.org, ehem+xen@m5p.com, bertrand.marquis@arm.com, andre.przywara@arm.com, Rahul.Singh@arm.com, Julien Grall , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Julien Grall Subject: [PATCH v2 5/7] xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro Date: Fri, 23 Oct 2020 16:41:54 +0100 Message-Id: <20201023154156.6593-6-julien@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20201023154156.6593-1-julien@xen.org> References: <20201023154156.6593-1-julien@xen.org> From: Julien Grall Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6: The BAD_MADT_ENTRY() macro is designed to work for all of the subtables of the MADT. In the ACPI 5.1 version of the spec, the struct for the GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in ACPI 6.0, the struct is 80 bytes long. But, there is only one definition in ACPICA for this struct -- and that is the 6.0 version. Hence, when BAD_MADT_ENTRY() compares the struct size to the length in the GICC subtable, it fails if 5.1 structs are in use, and there are systems in the wild that have them. This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable only, accounting for the difference in specification versions that are possible. The BAD_MADT_ENTRY() will continue to work as is for all other MADT subtables. This code is being added to an arm64 header file since that is currently the only architecture using the GICC subtable of the MADT. As a GIC is specific to ARM, it is also unlikely the subtable will be used elsewhere. Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.") Signed-off-by: Al Stone Acked-by: Will Deacon Acked-by: "Rafael J. Wysocki" [catalin.marinas@arm.com: extra brackets around macro arguments] Signed-off-by: Catalin Marinas Signed-off-by: Julien Grall Signed-off-by: Andre Przywara Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v2: - Patch added We may want to consider to also import: commit 9eb1c92b47c73249465d388eaa394fe436a3b489 Author: Jeremy Linton Date: Tue Nov 27 17:59:12 2018 +0000 arm64: acpi: Prepare for longer MADTs The BAD_MADT_GICC_ENTRY check is a little too strict because it rejects MADT entries that don't match the currently known lengths. We should remove this restriction to avoid problems if the table length changes. Future code which might depend on additional fields should be written to validate those fields before using them, rather than trying to globally check known MADT version lengths. Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com Signed-off-by: Jeremy Linton [lorenzo.pieralisi@arm.com: added MADT macro comments] Signed-off-by: Lorenzo Pieralisi Acked-by: Sudeep Holla Cc: Will Deacon Cc: Catalin Marinas Cc: Al Stone Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon --- xen/include/asm-arm/acpi.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h index 50340281a917..b52ae2d6ef72 100644 --- a/xen/include/asm-arm/acpi.h +++ b/xen/include/asm-arm/acpi.h @@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void); */ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); +/* Macros for consistency checks of the GICC subtable of MADT */ +#define ACPI_MADT_GICC_LENGTH \ + (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) + +#define BAD_MADT_GICC_ENTRY(entry, end) \ + (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ + (entry)->header.length != ACPI_MADT_GICC_LENGTH) + #ifdef CONFIG_ACPI extern bool acpi_disabled; /* Basic configuration for ACPI */