linux-kernel - Re: [PATCH] [RFC] x86: work around MPX Erratum

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: <20160503064354.GA11112@gmail.com>
Date:	Tue, 3 May 2016 08:43:54 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
	x86@...nel.org, Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] [RFC] x86: work around MPX Erratum


* Dave Hansen <dave@...1.net> wrote:

> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> Big core processors (Xeon/Core) are affected by an MPX erratum.
> This erratum can only be triggered when a system is not using
> Supervisor Mode Execution Prevention (SMEP).  To work around
> this, we ensure that MPX can only be used in cases where SMEP is
> present in the processor and enabled.

That's fair enough IMHO.

> MPX and SMEP are present together in the *vast* majority of
> cases, and the kernel does not generally execute code that is
> readable by userspace, so the real-world impact of this issue is
> expected to be very limited.
> 
> Note that we don't have a good way to tell if we are on an
> unaffected Atom processor or an affected Core/Xeon.  The
> solution for the moment is to just be conservative and assume
> that everything is affected unless explicitly known to be
> unaffected.

> +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c)
> +{
> +	/* Only family 6 is affected */
> +	if (c->x86 != 0x6)
> +		return 0;
> +
> +	/* We know these Atom models are unaffected, for sure */
> +	switch (c->x86_model) {
> +	case 0x5F: /* "Future Intel Atom ... Goldmont */
> +	case 0x5C: /* "Future Intel Atom ... Goldmont */
> +	     return 0;
> +	}
> +	/*
> +	 * We will get here on future unknown processors and all
> +	 * Core/Xeons.  They might be unaffected Atoms or
> +	 * affected Core/Xeons. Be conservative and assume
> +	 * processor is affected.
> +	 *
> +	 * Once the complete list of Core/Xeon models is known
> +	 * it can be added here, and the Atom list removed.
> +	 */
> +	return 1;

So instead of trying to sort out the erratum, could we not just generally make MPX 
dependent on SMEP and be done with it? MPX is a sophisticated security feature, 
and it makes little sense to not do SMEP if you have it available.

Anyone who is absolutely desperate to disable SMEP while enabling MPX is free to 
step in and make his case.

I.e. I think the simplest workaround would be to disable MPX if SMEP is disabled.

Thanks,

	Ingo