Re: [PATCH] [RFC] x86: work around MPX Erratum

[Dave Hansen <dave.hansen@intel.com>]

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.