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:43:36 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
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 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.