Received: by 10.223.176.46 with SMTP id f43csp2114838wra; Sun, 21 Jan 2018 11:39:04 -0800 (PST) X-Google-Smtp-Source: AH8x227VnTkbXMGgz9TF4LoDlsHmgZ2/er4JOv6iv2Lox20konpQDx0XPoFy0YRJgF4WnDv3sgS0 X-Received: by 10.99.174.69 with SMTP id e5mr5250061pgp.263.1516563544442; Sun, 21 Jan 2018 11:39:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516563544; cv=none; d=google.com; s=arc-20160816; b=gImgSIM6erDe7R+bdsGkjBOO9gzffQNXSSAmruP9/5ORHA/uCgw4DC5rDFt347T1S8 HJ67uBbHEaMrR6yAxosqRz64cow7tmzhi8sOc/d5cNvaZwy1eJiSvvAFWjpGSWtuKfcs WsVWilgLdIC9HXmfFX84NQ/lc5zPI9+0NEuCLYD6fR3PamW79wD9MuBq5tICm2bdF1Ef Rgatl86w0d3W1wGzhZPxRxoTIpH5KrJiVuVjEkBG3FWhUz7VNAGK+3NfPcnb2kmmzkaX bI7bIdWFK4AvPqUsmwZvjgREXopdP2RurdaE+3ywbi/Q1gcR4mE6ZBvOIpEBDhL+OtFN al2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=eYZmp4nr84/smpKgU7gkDlRUAqPT9CN4hx2QMstYQjs=; b=mrfDyYdRZmVcTYfKSvd+hnQNiT5XOZcWbl5NE4t+ANr56o2JDVpZLRwBeeVaIN3BAa LEi1SAYQ4yOn4D63JwljO8ExD/jMyWvCuxA8dAChhbdx4CKk1w5eYca12oPKH11uWWTU PnV2L4pZPJ2VDSUbflxQfFqa2Wt69rFdh7x769i/AeTDDlqx6MK0hwE555GeBuujFQe0 7X0kxMnnLRTMHwPTrXeTJHM1U0ey08C3un+pCLzP99LY4qh58LyQjlVy9pNwOOOJNcMQ gFz01MTfNpP5YPVuDr2u4Q9nvrxzVlchS1GN4rhRwPMSkNN9fg1YMroBqCxS5c6fcTgs a4EQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1-v6si1415688pld.427.2018.01.21.11.38.50; Sun, 21 Jan 2018 11:39:04 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751412AbeAUThm (ORCPT + 99 others); Sun, 21 Jan 2018 14:37:42 -0500 Received: from smtp.eu.citrix.com ([185.25.65.24]:49400 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbeAUThk (ORCPT ); Sun, 21 Jan 2018 14:37:40 -0500 X-IronPort-AV: E=Sophos;i="5.46,393,1511827200"; d="scan'208";a="66416615" Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB To: David Woodhouse , Borislav Petkov , KarimAllah Ahmed CC: , , , , , , , , , , References: <1516528149-9370-1-git-send-email-dwmw@amazon.co.uk> <1516528149-9370-6-git-send-email-dwmw@amazon.co.uk> <20180121180621.ufmc5m7nr6v4tjvc@pd.tnic> <31c52131-5f7a-8af0-3092-5fc9e322a734@amazon.com> <20180121190145.uuk3xizxejckth5s@pd.tnic> <1516563060.9814.52.camel@infradead.org> From: Andrew Cooper Message-ID: Date: Sun, 21 Jan 2018 19:37:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516563060.9814.52.camel@infradead.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/01/18 19:31, David Woodhouse wrote: > On Sun, 2018-01-21 at 20:01 +0100, Borislav Petkov wrote: >> so execution runs directly into the MSR write and the JMP is gone. >> >> So I don't see indirect branches anywhere... > Wait until the wind changes. > > Congratulations, you've just turned a potential GCC missed optimisation > into a kernel bug. We don't *care* that it's unlikely that GCC will > miss that optimisation. The point is that it doesn't *have* to do it, > and we don't *check*. > > cf. https://lkml.org/lkml/2018/1/12/176 > > > ... after which Peter went off and implemented that check, which is all > fine and dandy but let's not rely on backporting that too. It doesn't matter if an attacker can use SP1 to try and skip the IBPB. Exits to userspace/guest are serialising (with some retroactive updates to the architecture spec coming), so an attacker can't cause victim code to be executed before speculation has caught up and noticed that the IBPB did need to happen. ~Andrew