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]

Message-ID: <20160504064400.GA18084@gmail.com>
Date:	Wed, 4 May 2016 08:44:00 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Dave Hansen <dave.hansen@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	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


* Andy Lutomirski <luto@...capital.net> wrote:

> On Tue, May 3, 2016 at 2:43 PM, Dave Hansen <dave.hansen@...el.com> wrote:
> > On 05/03/2016 02:31 PM, Andy Lutomirski wrote:
> >> 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?
> >
> > First of all, with SMEP, it doesn't affect us.  At all.
> >
> > Without SMEP, there would have to be a page accessible to userspace that the 
> > kernel executes instructions from.  The only thing that I can think of that's 
> > normally user-accessible and not _controlled_ by userspace is the VDSO.  But 
> > the kernel never actually executes from it, so it doesn't matter here.
> >
> > I've heard reports of (but no actual cases in the wild of) folks remapping 
> > kernel text to be user-accessible so that userspace can execute it, or of 
> > having the kernel jump into user-provided libraries. Those are both obviously 
> > bonkers and would only be done with out-of-tree gunk, but even if somebody did 
> > that, they would be safe from the erratum, with this workaround.
> 
> I'm not convinced this is worth adding any code for, though.  If someone adds 
> out of tree crap that does this and manually turns off SMEP, I think they should 
> get to keep both pieces.  Frankly, I think I'd *prefer* if the kernel crashed 
> when calling user addresses like that just to discourage it.

So the thing is, this doesn't have to be any (or much) code per se: my suggestion 
was to make MPX depend on SMEP on the Kconfig level, so that it's not possible to 
build MPX without having SMEP.

Secondly, even if you were right and if this erratum didn't affect us, I'm still 
happy to use pretty much any excuse to further simplify the x86 security state 
space. 'This erratum suggests that the hardware might be borken without SMEP' is 
excuse enough in my book to couple MPX with SMEP.

All these zillions of flags and variants really only ever add new failure modes, 
they don't truly improve security, nor performance.

Thanks,

	Ingo