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]

Date:	Tue, 3 May 2016 14:31:44 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Dave Hansen <dave.hansen@...el.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] [RFC] x86: work around MPX Erratum

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