linux-kernel - RE: [RFC PATCH 00/56] Dynamic mitigations

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:
 <LV3PR12MB9265837FA51DFD9D2F11474D94E8A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 15 Oct 2025 15:51:01 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: Aaron Rainbolt <arraybolt3@...il.com>, Thomas Gleixner
	<tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Peter Zijlstra
	<peterz@...radead.org>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Ingo
 Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
	Alexander Graf <graf@...zon.com>, Boris Ostrovsky
	<boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 00/56] Dynamic mitigations

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Josh Poimboeuf <jpoimboe@...nel.org>
> Sent: Wednesday, October 15, 2025 10:43 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Aaron Rainbolt <arraybolt3@...il.com>; Thomas Gleixner
> <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter Zijlstra
> <peterz@...radead.org>; Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>;
> Ingo Molnar <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> x86@...nel.org; H . Peter Anvin <hpa@...or.com>; Alexander Graf
> <graf@...zon.com>; Boris Ostrovsky <boris.ostrovsky@...cle.com>; linux-
> kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 00/56] Dynamic mitigations
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Oct 15, 2025 at 01:53:31PM +0000, Kaplan, David wrote:
> > > If `root` is capable of setting `mitigations=off` via this interface,
> > > doesn't that somewhat defeat the purpose of denying `/proc/kcore`
> > > access in lockdown confidentiality mode? Assuming one is running on a
> > > CPU with some form of side-channel memory read vulnerability (which they
> > > very likely are), they can turn off all mitigations, then read kernel
> > > memory via one of those exploits.
> > >
> > > There should be a one-way switch to allow denying all further writes to
> > > this interface, so that once the system's mitigations are set properly,
> > > any further attempts to change them until the next reboot can be
> > > prevented.
> > >
> >
> > That's a good idea, there could be a separate mitigation_lock file
> > perhaps that once written to 1 denies any further changes.
>
> Wouldn't the enablement of lockdown mode effectively function as that
> one way switch?
>

I'm not too familiar with lockdown mode, but that gets enabled (with right cmdline options) during boot right?  I guess the question is would we want to allow any window for userspace to reconfigure things and then lock things down, or say that if you enable lockdown then this interface is completely disabled and you need to specify your mitigation options on the cmdline only.

--David Kaplan