From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 277FDC43441 for ; Sun, 25 Nov 2018 20:53:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E7D0220855 for ; Sun, 25 Nov 2018 20:53:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7D0220855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726672AbeKZHp1 (ORCPT ); Mon, 26 Nov 2018 02:45:27 -0500 Received: from mga02.intel.com ([134.134.136.20]:30872 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbeKZHp1 (ORCPT ); Mon, 26 Nov 2018 02:45:27 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2018 12:53:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,279,1539673200"; d="scan'208";a="98902911" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by FMSMGA003.fm.intel.com with ESMTP; 25 Nov 2018 12:53:30 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id DFC10309C88; Sun, 25 Nov 2018 12:53:30 -0800 (PST) Date: Sun, 25 Nov 2018 12:53:30 -0800 From: Andi Kleen To: Thomas Gleixner Cc: LKML , x86@kernel.org, Peter Zijlstra , Andy Lutomirski , Linus Torvalds , Jiri Kosina , Tom Lendacky , Josh Poimboeuf , Andrea Arcangeli , David Woodhouse , Tim Chen , Dave Hansen , Casey Schaufler , Asit Mallick , Arjan van de Ven , Jon Masters , Waiman Long , Greg KH , Dave Stewart , Kees Cook Subject: Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm() Message-ID: <20181125205330.GO13936@tassilo.jf.intel.com> References: <20181125183328.318175777@linutronix.de> <20181125185005.466447057@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181125185005.466447057@linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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