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

[Andy Lutomirski]

On May 3, 2016 2:05 PM, "Dave Hansen" <dave.hansen@xxxxxxxxx> 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?