lkml.org 
[lkml]   [2021]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
Date


> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Monday, February 8, 2021 11:14 AM
> To: Kaneda, Erik <erik.kaneda@intel.com>
> Cc: Rafael J. Wysocki <rafael@kernel.org>; Shawn Guo
> <shawn.guo@linaro.org>; Linux ARM <linux-arm-
> kernel@lists.infradead.org>; ACPI Devel Maling List <linux-
> acpi@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE
> (ACPICA) <devel@acpica.org>; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; Moore,
> Robert <robert.moore@intel.com>
> Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using
> existing buffer"
>
> On Mon, 8 Feb 2021 at 20:07, Kaneda, Erik <erik.kaneda@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Rafael J. Wysocki <rafael@kernel.org>
> > > Sent: Monday, February 8, 2021 5:01 AM
> > > To: Shawn Guo <shawn.guo@linaro.org>; Ard Biesheuvel
> > > <ardb@kernel.org>; Kaneda, Erik <erik.kaneda@intel.com>
> > > Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling
> > > List <linux-acpi@vger.kernel.org>; Linux Kernel Mailing List <linux-
> > > kernel@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE
> > > (ACPICA) <devel@acpica.org>; Wysocki, Rafael J
> > > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; Moore,
> > > Robert <robert.moore@intel.com>
> > > Subject: Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by
> using
> > > existing buffer"
> > >
> > > On Sat, Feb 6, 2021 at 11:49 AM Shawn Guo <shawn.guo@linaro.org>
> 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?

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

Erik
\
 
 \ /
  Last update: 2021-02-08 21:44    [W:0.669 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site