Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4303725pxb; Mon, 8 Feb 2021 12:59:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJy//3VHP1uA99kQRIrD+IglsMr2EOM+CcfiaTN79AAVICB5Ywk8iS4ocCTa/CRFMaEAmnic X-Received: by 2002:a17:906:4348:: with SMTP id z8mr19016123ejm.371.1612817965144; Mon, 08 Feb 2021 12:59:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612817965; cv=none; d=google.com; s=arc-20160816; b=VNirzbduNRN9phnTHl4nKQiG+CW5r3aoMOIOsRx5LqWsNhl1duN4Is3nzJlwqcutk/ SHAL9teVlcBPMxyqFQFAWplCQlNYC2M82DqxkkjNa0TmMjCsvi7929qf+kdnTcCKqAwV De4DsIKroLxvJq/8qMNY/L32VfidzezWcQaRrbGkg8vPh0WDon5E4eURk9f4sEVv2QD5 FKelVv2EhPKVTjHE001DBQcUPPtlTwTKb9KVn6ze1FJCn+t0FMy3jL/NePTLNdjkkQUD LdflUvqmuNOB9HPRN5JF8i+Q4PSS5afym2K6Dhrb8Dv96fUCT67ZEhsFwhwFen64X1ea HUTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=U/+E51uWrkFUj4ZO78qAQAKtSNN24kWemmORiGVhfW4=; b=W+xJ3TjB5HCxtWs3p4Kcem0virf4wJPTAhL+rC3x7HKnzQXZkGrYGo9qwBzUmZxFwp d54bQs/WdInZrVu3nsLRwZfc4gfYk5JYgLjnsBjF3IkdTV3LOKkGHQvSzPbU7M65mgS9 yPgJj6WugVLn5GXqrRVt5m6LGyryE1HzGYCbaSlHi7YKTxiJgmqSMgKjsNHmA2ADcsdP 1PVoayUs2kla5tAe26ALtWnquz3PmEFGHC6bCtEInAzl9wfSzd9Hv9kMuzQEMC7JjsnJ hfkanly4tl/JUAoF391FLjOaxp3o/hwNmyM5cnKiMXgzRt+uEQgnT3jrpbzVqfbA3Cxy wsHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="qV/jNlyh"; 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 x14si9591951eds.256.2021.02.08.12.59.01; Mon, 08 Feb 2021 12:59:25 -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="qV/jNlyh"; 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 S233460AbhBHU5j (ORCPT + 99 others); Mon, 8 Feb 2021 15:57:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:44714 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236461AbhBHTrr (ORCPT ); Mon, 8 Feb 2021 14:47:47 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 779DB64E92; Mon, 8 Feb 2021 19:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612813626; bh=U/+E51uWrkFUj4ZO78qAQAKtSNN24kWemmORiGVhfW4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qV/jNlyhVKK6iYV9y31vsr+WPOz0Agt7SyDvuJY5Lajbb9+fc8g0waKmgoewfBpBy ahqwfBBN4jD8fwlfMchsSgzuhDCi5JNzXJFgPf5iSJ4BkZRX6nxpeCRAp+/CBMubyr Y2Xvi40KH1EQLM6m4I0bKODt98gOrMRrSFXMWNsslCsFAZw/PhBFscl1VjIBpArYl/ Fcg4kcF+AZu0gUuCJBIlkt8R9d41G34wVDv3ThdlJtzeZqy5h8jEaIg3SrgzCTF+Aq t+VQCWa/xSYAMhu0tlPoW24yG2FXBO6WupP8BONUgHHxMXWsQXoMLB0kxp2ZYPVlwk xJf4nRB6Mfadw== Received: by mail-ot1-f46.google.com with SMTP id s107so15284064otb.8; Mon, 08 Feb 2021 11:47:06 -0800 (PST) X-Gm-Message-State: AOAM531Tyl11Gs4G3VHiSsiQHLph0cX/nVS8fmBc+mcCOibCxpq52HYA MYWH8vtRFPPOxKVwcURHj3T+A1zFbQTFXwOo0Aw= X-Received: by 2002:a05:6830:1285:: with SMTP id z5mr4473212otp.90.1612813625708; Mon, 08 Feb 2021 11:47:05 -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:46:53 +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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Feb 2021 at 20:30, Kaneda, Erik wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Monday, February 8, 2021 11:14 AM > > To: Kaneda, Erik > > Cc: Rafael J. Wysocki ; Shawn Guo > > ; Linux ARM > kernel@lists.infradead.org>; ACPI Devel Maling List > acpi@vger.kernel.org>; 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 using > > existing buffer" > > > > 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 > > using > > > > 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 with > > > > > > 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 initrd > > 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 future 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 > > regardless 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. > > I'm not knowledgeable on TPM but I'm curious - what happens when the TPM detects that these ACPI tables are modified? > That depends on the policy implemented in user space. The TPM itself does not detect this change, but these ACPI tables will no longer match their SHA hashes in the TPM event log, and this is something we should really avoid. > > > > 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. > > I agree that this would be a more efficient approach > Indeed.