Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4291080pxb; Mon, 8 Feb 2021 12:35:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJx5ntP1G2ZVaVPgxWDTARh1PbNfFtF35V8mrl22oFEmUOND1lN6Jmmx3amo9WT0iC3RUMFE X-Received: by 2002:aa7:d817:: with SMTP id v23mr18391303edq.192.1612816554903; Mon, 08 Feb 2021 12:35:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612816554; cv=none; d=google.com; s=arc-20160816; b=ve2N0SRvrLFl676BEjvtB9dBJD7XPUlqvpmGzdUiyXjh5S8GTW3IPnnnGyM0R41Cjd Cs1ZtZzKxorslaXPgrIF9EetgUZKc1C43yXuo4oH9kvdl+r+FisghQAD6bzer+eQ3CV9 QeRo0H4KUQm+ZL6Og5MLySXEaVOMuT0r2vzqEeHUdVjiOh4mhXWgbU8b1zKpSyisIh/5 FOK5V1/uFywdbGdGIGWHbUVlG7RVrBmoQtD5Ym8+wpXlGdDDKU7PW0mPH8c6aVsr29UD air6ca8T78TBQSVPZQ2qEoeWPoAi6WJbc/srkqU0HMRvd+10Vsdvcwge9ykhtpfvu4xs SUrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=3Sei4KZaQlN8EaRCqEQMXisB257JKwJryVwgk/STYDk=; b=PAZkGheSM0cZ8r1elFVqP9vSetRcd9vZTZcd1bJQ4q6063pDTqQRE072SnJv39XQzl iEe3AxzCpJ+0YO1+v0XuzmqaEVDLBp/D/2KeOseD4G9W8yWgNKqCdtErgADBhI0kw83q MuO8ELgDVJGOkzMJxZLBfd6wJKP3+P9XYTHm3+rDoUYe/V+jTtUsRbRyd5lanyja9aRc apaMy/7/mVc89FMAQrS6DYrJDdsn/1GV2Q5CJmfaidNOvWtzf6X8b2JONqJn+EnqKFt9 7LzIsM3KgQJ+vI56q6E/pp0Fe16Q8ZKyOg4k6k2Vjp9F5eYksLddey9yqotiWMgYi3Oy fU7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WNAS3Bdo; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gz19si12271436ejb.645.2021.02.08.12.35.27; Mon, 08 Feb 2021 12:35:54 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=WNAS3Bdo; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231966AbhBHUd7 (ORCPT + 99 others); Mon, 8 Feb 2021 15:33:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:37236 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233264AbhBHTOt (ORCPT ); Mon, 8 Feb 2021 14:14:49 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E96C264E85; Mon, 8 Feb 2021 19:14:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612811647; bh=3Sei4KZaQlN8EaRCqEQMXisB257JKwJryVwgk/STYDk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WNAS3BdoCkEttS26MrYDbXFy3SvlCHWPM3VfUA1EdBbc0MeCMtU4i0QdgJDytzKIe sdjM6G337PjWO+LFk+sOq8YJaQjrjY6FailaNzYjw76iDDWd6fN1tYsjFJTIdsIJ3K 5FCpzInLBPcvlMhfebIadkGRV+KIIIgJenZLfcCBlrTT78XolCcKblTkipvqX+CPxT 6B/ivpZXuzhO0IaNwhR/JBzDP71AdPE/QTl5sp7sRDsKuvItMqsghatcvjyvx+aR2N Z7zZtjvrTPteLurZhWDvpGGHtVfYMxHY0Ebl+O77DNG/8CY9IPB3TGXyZ0HFt4IW1Z KCvTLA3pP6DYA== Received: by mail-oo1-f41.google.com with SMTP id x23so3705486oop.1; Mon, 08 Feb 2021 11:14:06 -0800 (PST) X-Gm-Message-State: AOAM531fUqnstvwBF45d+yXDxvUVW7AkV1anVS1WJan2PZyqFVbWYzwm Ve+pH+nMsnztjxcRo8i0B8PgsaBUck1WYBWhYNU= X-Received: by 2002:a4a:e1e4:: with SMTP id u4mr13654774ood.41.1612811646204; Mon, 08 Feb 2021 11:14:06 -0800 (PST) MIME-Version: 1.0 References: <20210206084937.20853-1-ardb@kernel.org> <20210206104854.GC27503@dragon> In-Reply-To: From: Ard Biesheuvel Date: Mon, 8 Feb 2021 20:13:54 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer" To: "Kaneda, Erik" Cc: "Rafael J. Wysocki" , Shawn Guo , Linux ARM , ACPI Devel Maling List , Linux Kernel Mailing List , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , "Wysocki, Rafael J" , Len Brown , "Moore, Robert" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Feb 2021 at 20:07, Kaneda, Erik wrote: > > > > > -----Original Message----- > > From: Rafael J. Wysocki > > Sent: Monday, February 8, 2021 5:01 AM > > To: Shawn Guo ; Ard Biesheuvel > > ; Kaneda, Erik > > Cc: Linux ARM ; ACPI Devel Maling > > List ; Linux Kernel Mailing List > kernel@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE > > (ACPICA) ; Wysocki, Rafael J > > ; Len Brown ; Moore, > > Robert > > Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by us= ing > > existing buffer" > > > > On Sat, Feb 6, 2021 at 11:49 AM Shawn Guo wrote: > > > > > > On Sat, Feb 06, 2021 at 09:49:37AM +0100, Ard Biesheuvel wrote: > > > > This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4. > > > > > > Hi Bob, Ard and Rafael, > > > > > The 'exisitng buffer' in this case is the firmware provided table, = and > > > > we should not modify that in place. This fixes a crash on arm64 wit= h > > > > initrd table overrides, in which case the DSDT is not mapped with > > > > read/write permissions. > > Since this code runs on basically every _HID and _CID invocation, I would= have expected this kind of revert to come in for kernels that do not use i= nitrd override... So it sounds like there is a difference between how pages= are mapped for initrd table overrides and tables exposed through the XSDT = for ARM.. I think it would be easier for us to make these fixes in the futu= re if we could all come to a consensus on whether if we should assume that = these pages are writable or not. > > Should we assume that all ACPI tables are non-writable and read only rega= rdless of initrd override and architecture? > ACPI tables are measured into the TPM on measured boot systems, and checksummed, so I don't think we should ever modify them in place. But if we need code like this, it should be conditional at the very least, i.e., it should only rewrite _HIDs and _CIDs if they are incorrect to begin with.