linux-kernel - Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch

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: <20181125205330.GO13936@tassilo.jf.intel.com>
Date:   Sun, 25 Nov 2018 12:53:30 -0800
From:   Andi Kleen <ak@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jiri Kosina <jkosina@...e.cz>,
        Tom Lendacky <thomas.lendacky@....com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Dave Stewart <david.c.stewart@...el.com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB
 in switch_mm()

> 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.

Because of concerns with that the counter ID was used instead.

The ID can wrap too, but since it's 64bit, it will take very long.

-Andi