[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGWyY8vFAdpYJvxtNR5nrYaKQg9yL0o5Sp0BbnQnZaRCA@mail.gmail.com>
Date: Sat, 6 Feb 2021 11:17:57 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Shawn Guo <shawn.guo@...aro.org>
Cc: Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Catalin Marinas <catalin.marinas@....com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Sudeep Holla <sudeep.holla@....com>,
Will Deacon <will@...nel.org>, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 2/2] arm64/acpi: disallow writeable AML opregion
mapping for EFI code regions
On Sat, 6 Feb 2021 at 09:10, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Sat, 6 Feb 2021 at 04:11, Shawn Guo <shawn.guo@...aro.org> wrote:
> >
> > Hi Ard,
> >
> > On Fri, Jun 26, 2020 at 05:58:32PM +0200, Ard Biesheuvel wrote:
> > > Given that the contents of EFI runtime code and data regions are
> > > provided by the firmware, as well as the DSDT, it is not unimaginable
> > > that AML code exists today that accesses EFI runtime code regions using
> > > a SystemMemory OpRegion. There is nothing fundamentally wrong with that,
> > > but since we take great care to ensure that executable code is never
> > > mapped writeable and executable at the same time, we should not permit
> > > AML to create writable mapping.
> > >
> > > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> >
> > I'm booting Lenovo Flex 5G laptop with ACPI, and seeing this change
> > causes a memory abort[1] when upgrading ACPI tables via initrd[2].
> > Dropping this change seems to fix the issue for me. But does that
> > looks like a correct fix to you?
> >
> > Shawn
> >
> > [1] https://fileserver.linaro.org/s/iDe9SaZeNNkyNxG
> > [2] Documentation/admin-guide/acpi/initrd_table_override.rst
> >
>
> Can you check whether reverting
>
> 32cf1a12cad43358e47dac8014379c2f33dfbed4
>
> fixes the issue too?
>
> If it does, please report this as a regression. The OS should not
> modify firmware provided tables in-place, regardless of how they were
> delivered.
>
That patch modifies firmware provided tables in-place, which
invalidates checksums and TPM measurements, so it needs to be reverted
in any case, and I have already sent out the patch for doing so.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
