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] [day] [month] [year] [list]
Message-ID: <20250212231646.gyf4zbqlq7f6kqqf@jpoimboe>
Date: Wed, 12 Feb 2025 15:16:46 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: 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>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 06/35] x86/bugs: Restructure mmio mitigation

On Wed, Feb 12, 2025 at 05:28:23PM +0000, Kaplan, David wrote:
> > > > Right here it does the following:
> > > >
> > > >         /*
> > > >          * Enable CPU buffer clear mitigation for host and VMM, if also affected
> > > >          * by MDS or TAA. Otherwise, enable mitigation for VMM only.
> > > >          */
> > > >         if (boot_cpu_has_bug(X86_BUG_MDS) ||
> > > > (boot_cpu_has_bug(X86_BUG_TAA) &&
> > > >                                               boot_cpu_has(X86_FEATURE_RTM)))
> > > >                 setup_force_cpu_cap(X86_FEATURE_CLEAR_CPU_BUF);
> > > >
> > > > Isn't that a cross-mitigation dependency?  i.e. if
> > > > X86_FEATURE_CLEAR_CPU_BUF gets enabled here then the other
> > > > mitigations would need to update their mitigation reporting?
> > >
> > > I don't think so, nobody should be looking at
> > > X86_FEATURE_CLEAR_CPU_BUF to determine their mitigation selection,
> > > they should only be looking at the other variables like taa_mitigation
> > > as done in the verw_mitigation_enabled() function.
> >
> > But isn't that a bug in the reporting?  AFAICT one of the main motivations for the
> > cross dependencies (and the *_update_mitigation()
> > functions) is to fix the reporting if something actually ends up getting mitigated by
> > something else.
> >
> > For example, "mds=off tsx_async_abort=full" results in both MDS and TAA being
> > reported "Mitigated", because they share the same VERW mitigation.
> >
> > But in the above case, with X86_BUG_MDS, "mds=off mmio_stale_data=full"
> > shows MDS as vulnerable despite it actually being mitigated by VERW.
> 
> Does it?  In that case, mds_update_mitigation() will see that
> verw_mitigation_enabled() is true (because
> mmio_mitigation!=MMIO_MITIGATION_OFF) and then enable the mds
> mitigation.

Hrmmm, that's a bit of a maze.

static bool __init verw_mitigation_enabled(void)
{
	return (mds_mitigation != MDS_MITIGATION_OFF ||
		(taa_mitigation != TAA_MITIGATION_OFF &&
		 taa_mitigation != TAA_MITIGATION_TSX_DISABLED) ||
		mmio_mitigation != MMIO_MITIGATION_OFF ||
		rfds_mitigation != RFDS_MITIGATION_OFF);
}

That seems to work by accident.  And I haven't managed to convince
myself it works for all edge cases.

Technically, checking !MMIO_MITIGATION_OFF alone isn't enough: MMIO only
needs global VERW if the MDS or TAA bugs are present.

Also, without ucode, the RFDS mitigation doesn't even attempt VERW for
some unknown reason, so just checking !RFDS_MITIGATION_OFF isn't
sufficient.

I'm thinking it should be something like

static bool __init taa_vulnerable(void)
{
	boot_cpu_has_bug(X86_BUG_TAA) && boot_cpu_has(X86_FEATURE_RTM);
}

static bool __init mmio_needs_verw(void)
{
	return boot_cpu_has_bug(X86_BUG_MDS) || taa_vulnerable();
}

static bool __init rfds_needs_ucode(void)
{
	return !(x86_arch_cap_msr & ARCH_CAP_RFDS_CLEAR);
}

static bool __init verw_mitigation_enabled(void)
{
	return mds_mitigation != MDS_MITIGATION_OFF ||
		(taa_mitigation != TAA_MITIGATION_OFF && taa_vulnerable()) ||
		(mmio_mitigation != MMIO_MITIGATION_OFF && mmio_needs_verw());
		(rfds_mitigation != RFDS_MITIGATION_OFF && !rfds_needs_ucode());
}

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ