On May 3, 2016 2:05 PM, "Dave Hansen" <dave.han...@intel.com> wrote:
>
> 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.
>
>
Having actually read the erratum: how can this affect Linux at all
under any scenario where user code hasn't already completely
compromised the kernel?
I.e. why do we care about this erratum?
