lkml.org 
[lkml]   [2016]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] [RFC] x86: work around MPX Erratum
On May 3, 2016 2:05 PM, "Dave Hansen" <dave.hansen@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?

\
 
 \ /
  Last update: 2016-05-04 00:01    [W:0.101 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site