UBUNTU: SAUCE: acpi: disallow loading configfs acpi tables when locked down
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.
9ebf8f8...
by
"Christopher M. Riedl" <email address hidden>
powerpc/xmon: Restrict when kernel is locked down
Xmon should be either fully or partially disabled depending on the
kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and prevent user
entry into xmon when lockdown=confidentiality. Xmon checks the lockdown
state on every attempted entry:
(1) during early xmon'ing
(2) when triggered via sysrq
(3) when toggled via debugfs
(4) when triggered via a previously enabled breakpoint
The following lockdown state transitions are handled:
(1) lockdown=none -> lockdown=integrity
set xmon read-only mode
(2) lockdown=none -> lockdown=confidentiality
clear all breakpoints, set xmon read-only mode,
prevent user re-entry into xmon
(3) lockdown=integrity -> lockdown=confidentiality
clear all breakpoints, set xmon read-only mode,
prevent user re-entry into xmon
Suggested-by: Andrew Donnellan <email address hidden>
Signed-off-by: Christopher M. Riedl <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
Link: https://<email address hidden>
(backported from commit 69393cb03ccdf29f3b452d3482ef918469d1c098)
Signed-off-by: Seth Forshee <email address hidden>
1a029b0...
by
"Christopher M. Riedl" <email address hidden>
powerpc/xmon: add read-only mode
Operations which write to memory and special purpose registers should be
restricted on systems with integrity guarantees (such as Secure Boot)
and, optionally, to avoid self-destructive behaviors.
Add a config option, XMON_DEFAULT_RO_MODE, to set default xmon behavior.
The kernel cmdline options xmon=ro and xmon=rw override this default.
The following xmon operations are affected:
memops:
disable memmove
disable memset
disable memzcan
memex:
no-op'd mwrite
super_regs:
no-op'd write_spr
bpt_cmds:
disable
proc_call:
disable
Signed-off-by: Christopher M. Riedl <email address hidden>
Reviewed-by: Oliver O'Halloran <email address hidden>
Reviewed-by: Andrew Donnellan <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 0acb5f64560a052fd66ab37b212a72964847160f)
Signed-off-by: Seth Forshee <email address hidden>
610cd4e...
by
Matthew Garrett <email address hidden>
efi: Restrict efivar_ssdt_load when the kernel is locked down
efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an
EFI variable, which gives arbitrary code execution in ring 0. Prevent
that when the kernel is locked down.
1beaa3b...
by
Javier Martinez Canillas <email address hidden>
efi/efi_test: Lock down /dev/efi_test and require CAP_SYS_ADMIN
The driver exposes EFI runtime services to user-space through an IOCTL
interface, calling the EFI services function pointers directly without
using the efivar API.
Disallow access to the /dev/efi_test character device when the kernel is
locked down to prevent arbitrary user-space to call EFI runtime services.
Also require CAP_SYS_ADMIN to open the chardev to prevent unprivileged
users to call the EFI runtime services, instead of just relying on the
chardev file mode bits for this.
The main user of this driver is the fwts [0] tool that already checks if
the effective user ID is 0 and fails otherwise. So this change shouldn't
cause any regression to this tool.
UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when not supported
When SRBDS is mitigated by TSX OFF, update_srbds_msr will still read and
write to MSR_IA32_MCU_OPT_CTRL even when that is not supported by the
microcode.
Checking for X86_FEATURE_SRBDS_CTRL as a CPU feature available makes more
sense than checking for SRBDS_MITIGATION_UCODE_NEEDED as the the found
"mitigation".
CVE-2020-0543
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: John Johansen <email address hidden>
Acked-by: Steve Beattie <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
