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: <CAHmME9oemScgo2mg8fzqtJCbKJfu-op0WvG5RcpBCS1hHNmpZw@mail.gmail.com>
Date:   Tue, 16 Jun 2020 16:20:41 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Len Brown <lenb@...nel.org>, rjw@...ysocki.net
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] acpi: disallow loading configfs acpi tables when locked down

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ