Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 26 Nov 2018 08:10:45 +0100 (CET)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Andy Lutomirski <luto@amacapital.net>
cc:     Andi Kleen <ak@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jiri Kosina <jkosina@suse.cz>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Casey Schaufler <casey.schaufler@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        Jon Masters <jcm@redhat.com>,
        Waiman Long <longman9394@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Dave Stewart <david.c.stewart@intel.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB
 in switch_mm()
In-Reply-To: <92833780-41BE-446E-A676-925BA1EC93D9@amacapital.net>
Message-ID: <alpine.DEB.2.21.1811260751030.1684@nanos.tec.linutronix.de>
References: <20181125183328.318175777@linutronix.de> <20181125185005.466447057@linutronix.de> <20181125205330.GO13936@tassilo.jf.intel.com> <alpine.DEB.2.21.1811252316560.1684@nanos.tec.linutronix.de> <92833780-41BE-446E-A676-925BA1EC93D9@amacapital.net>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1385769263-1543216246=:1684"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1385769263-1543216246=:1684
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT

On Sun, 25 Nov 2018, Andy Lutomirski wrote:
> > On Nov 25, 2018, at 2:20 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Sun, 25 Nov 2018, Andi Kleen wrote:
> > 
> >>> The current check whether two tasks belong to the same context is using the
> >>> tasks context id. While correct, it's simpler to use the mm pointer because
> >>> it allows to mangle the TIF_SPEC_IB bit into it. The context id based
> >>> mechanism requires extra storage, which creates worse code.
> >> 
> >> [We tried similar in some really early versions, but it was replaced
> >> with the context id later.]
> >> 
> >> One issue with using the pointer is that the pointer can be reused
> >> when the original mm_struct is freed, and then gets reallocated
> >> immediately to an attacker. Then the attacker may avoid the IBPB.
> >> 
> >> Given it's probably hard to generate any reasonable leak bandwidth with
> >> such a complex scenario, but it still seemed better to close the hole.
> > 
> > Sorry, but that's really a purely academic exercise. 
> 
> I would guess that it’s actually very easy to force mm_struct* reuse.
> Don’t the various allocators try to allocate hot memory?  There’s nothing
> hotter than a just-freed allocation of the same size.

Sure, but this is about a indirect branch predictor attack against
something which reuses the mm.

So you'd need to pull off:

   P1 poisons branch predictor
   P1 exit

   P2 starts and resuses mm(P1) and uses the poisoned branch predictor

the only thing between P1 and P2 is either idle or some other kernel
thread, but no other user task. If that happens then the code would not
issue IBPB as it assumes to switch back to the same process.

Even if you can pull that off the speculation would hit the startup code of
P2, which is truly a source of secret information. Creating a valuable
attack based on mm reuse is really less proabable than a lottery jackpot.

So using mm is really good enough and results in better assembly code which
is surely more valuable than addressing some hypothetical hole.

Thanks,

	tglx
--8323329-1385769263-1543216246=:1684--