linux-kernel - RE: [PATCH] acpi: disallow loading configfs acpi tables when locked down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR11MB159995958420653FBC6D2DE2F09A0@MWHPR11MB1599.namprd11.prod.outlook.com>
Date:   Wed, 17 Jun 2020 16:52:10 +0000
From:   "Kaneda, Erik" <erik.kaneda@...el.com>
To:     Ard Biesheuvel <ardb@...nel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>
CC:     Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        LKML <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: RE: [PATCH] acpi: disallow loading configfs acpi tables when locked
 down



> -----Original Message-----
> From: linux-acpi-owner@...r.kernel.org <linux-acpi-
> owner@...r.kernel.org> On Behalf Of Ard Biesheuvel
> Sent: Wednesday, June 17, 2020 1:38 AM
> To: Jason A. Donenfeld <Jason@...c4.com>
> Cc: Len Brown <lenb@...nel.org>; Rafael J. Wysocki <rjw@...ysocki.net>;
> LKML <linux-kernel@...r.kernel.org>; ACPI Devel Maling List <linux-
> acpi@...r.kernel.org>; Kernel Hardening <kernel-
> hardening@...ts.openwall.com>
> Subject: Re: [PATCH] acpi: disallow loading configfs acpi tables when locked
> down
> 
> On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <Jason@...c4.com>
> wrote:
> >
> > Hi Rafael, Len,
> >
> > Looks like I should have CC'd you on this patch. This is probably
> > something we should get into 5.8-rc2, so that it can then get put into
> > stable kernels, as some people think this is security sensitive.
> > Bigger picture is this:
> >
> > https://data.zx2c4.com/american-unsigned-language-2.gif
> > https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png
> >
Hi,

> > Also, somebody mentioned to me that Microsoft's ACPI implementation
> > disallows writes to system memory as a security mitigation. I haven't
> > looked at what that actually entails, but I wonder if entirely
> > disabling support for ACPI_ADR_SPACE_SYSTEM_MEMORY would be
> sensible.

No, Windows uses these as well. They might have some restriction on which areas are allowed though.
With that said, there are plenty of use cases (SMI handlers, power management, etc) where this is needed.
Disabling SystemMemory would definitely break existing systems.

Erik
> > I haven't looked at too many DSDTs. Would that break real hardware, or
> > does nobody do that? Alternatively, the range of acceptable addresses
> > for SystemMemory could exclude kernel memory. Would that break
> > anything? Have you heard about Microsoft's mitigation to know more
> > details on what they figured out they could safely restrict without
> > breaking hardware? Either way, food for thought I suppose.
> >
> 
> ACPI_ADR_SPACE_SYSTEM_MEMORY may be used for everything that is
> memory
> mapped, i.e., PCIe ECAM space, GPIO control registers etc.
> 
> I agree that using ACPI_ADR_SPACE_SYSTEM_MEMORY for any memory that
> is
> under the kernel's control is a bad idea, and this should be easy to
> filter out: the SystemMemory address space handler needs the ACPI
> support routines to map the physical addresses used by AML into
> virtual kernel addresses, so all these accesses go through
> acpi_os_ioremap(). So as a first step, it should be reasonable to put
> a lockdown check there, and fail any access to OS owned memory if
> lockdown is enabled, and print a warning if it is not.