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: <57291268.3060006@intel.com>
Date:	Tue, 3 May 2016 14:04:40 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, 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

On 05/02/2016 11:43 PM, Ingo Molnar wrote:
>> > +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.

My concern was not necessarily with folks booting with 'nosmep', but
with processors that have MPX present and SMEP fused off (or made
unavailable by a hypervisor) and which are unaffected by this issue.

People would have to be very careful to never create a processor which
did not have SMEP but did have MPX, since MPX would effectively be
unusable on such a processor.