From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756696AbcECVni (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 May 2016 17:43:38 -0400
Received: from mga09.intel.com ([134.134.136.24]:20634 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756430AbcECVnh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 May 2016 17:43:37 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,574,1455004800"; 
   d="scan'208";a="968006195"
Subject: Re: [PATCH] [RFC] x86: work around MPX Erratum
To: Andy Lutomirski <luto@amacapital.net>
References: <20160502220341.9E8C34FC@viggo.jf.intel.com>
 <20160503064354.GA11112@gmail.com> <57291268.3060006@intel.com>
 <CALCETrUiaN9+BvEeO7n6L5AQmSrY_Y1LU7xftRjqvmKLcxROnQ@mail.gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <57291B88.6010702@intel.com>
Date: Tue, 3 May 2016 14:43:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CALCETrUiaN9+BvEeO7n6L5AQmSrY_Y1LU7xftRjqvmKLcxROnQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.