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-next>] [day] [month] [year] [list]
Date: Fri, 19 Apr 2024 17:05:53 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>, 
	Michael Ellerman <mpe@...erman.id.au>, Geert Uytterhoeven <geert@...ux-m68k.org>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Will Deacon <will@...nel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Sean Christopherson <seanjc@...gle.com>
Subject: [PATCH v2 0/2] cpu: Fix default mitigation behavior

Linus, I Cc'd you on this as patch 1 fixes a goof that causes mitigations
to be completely disabled on all !x86 architectures, and it'd be nice to
fix that in rc5.  There was a decent bit of discussion on how exactly to
juggle the Kconfigs, and so I don't expect anyone to include this in a pull
request for rc5.

The discussion didn't fully resolve, i.e. this hasn't gotten a thumbs up
from the affected parties, but I think/hope my approach here is minimal
enough for other architectures (just restores previous behavior), and
shouldn't result in a huge amount of churn if we decide to go in a
different direction.

TL;DR: please grab patch 1 directly if you think it's worth squeezing into
rc5, and isn't completely crazy.

Thanks!


Patch 2 is probably 6.9 material, but is definitely not rc5 material.  It
disallows retroactively enabling mitigations via command line if the kernel
was built with CPU_MITIGATIONS=n, as it's infeasible for x86 to provide
sane, predictable behavior for this scenario.

v2:
 - Rework the Kconfigs so that there's a single user-visible CPU_MITIGATION
   config. [Everyone]
 - Define CPU_MITIGATIONS in arch/Kconfig. [Josh]
 - Completely compile out the cpu_mitigations code if CPU_MITIGATIONS=n,
   e.g. to make impossible to end up in a half-baked state where
   cpu_mitigations ends up enabled but the kernel wasn't compiled with
   mitigations enabled.

v1: https://lore.kernel.org/all/20240417001507.2264512-1-seanjc@google.com

Sean Christopherson (2):
  cpu: Re-enable CPU mitigations by default for !X86 architectures
  cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n

 .../admin-guide/kernel-parameters.txt         |  3 +++
 arch/Kconfig                                  |  8 ++++++++
 arch/x86/Kconfig                              | 19 ++++++++++++-------
 include/linux/cpu.h                           | 11 +++++++++++
 kernel/cpu.c                                  | 13 ++++++++++---
 5 files changed, 44 insertions(+), 10 deletions(-)


base-commit: 96fca68c4fbf77a8185eb10f7557e23352732ea2
-- 
2.44.0.769.g3c40516874-goog


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ