Like other vectors already patched, this one here allows the root user
to load ACPI tables, which enables arbitrary physical address writes,
which in turn makes it possible to disable lockdown. This patch prevents
this by checking the lockdown status before allowing a new ACPI table to be
installed. The link in the trailer shows a PoC of how this might be
used.
Link: https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh
Cc: [email protected]
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
drivers/acpi/acpi_configfs.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index ece8c1a921cc..88c8af455ea3 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/configfs.h>
#include <linux/acpi.h>
+#include <linux/security.h>
#include "acpica/accommon.h"
#include "acpica/actables.h"
@@ -28,7 +29,10 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg,
{
const struct acpi_table_header *header = data;
struct acpi_table *table;
- int ret;
+ int ret = security_locked_down(LOCKDOWN_ACPI_TABLES);
+
+ if (ret)
+ return ret;
table = container_of(cfg, struct acpi_table, cfg);
--
2.27.0
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
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.
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.
Jason
On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <[email protected]> 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
>
> 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.
> 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.
On Wed, Jun 17, 2020 at 2:38 AM Ard Biesheuvel <[email protected]> wrote:
>
> On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <[email protected]> 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
> >
> > 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.
> > 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.
Makes sense. Though I was thinking of doing this unconditionally, not
just for lockdown, as a "realer" security mitigation (hence CCing
kernel-hardening), against bugs that manage to mess with acpi things.
A second mitigation might be marking inmemory acpi bytecode pages as
read only.
> -----Original Message-----
> From: [email protected] <linux-acpi-
> [email protected]> On Behalf Of Ard Biesheuvel
> Sent: Wednesday, June 17, 2020 1:38 AM
> To: Jason A. Donenfeld <[email protected]>
> Cc: Len Brown <[email protected]>; Rafael J. Wysocki <[email protected]>;
> LKML <[email protected]>; ACPI Devel Maling List <linux-
> [email protected]>; Kernel Hardening <kernel-
> [email protected]>
> Subject: Re: [PATCH] acpi: disallow loading configfs acpi tables when locked
> down
>
> On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <[email protected]>
> 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.
Hi,
On Wed, Jun 17, 2020 at 12:20 AM Jason A. Donenfeld <[email protected]> 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
I was offline during the last week, sorry.
Applied as 5.8-rc material with some subject/changelog edits, thanks!
