Received: by 10.223.185.116 with SMTP id b49csp2359779wrg; Mon, 12 Feb 2018 08:22:36 -0800 (PST) X-Google-Smtp-Source: AH8x225cvgFx6BXNWsQBoln+zofZIbhxwW2Mj6T3D75yUn5QYwAKfsr/jmySLpofyfUpk/7680rK X-Received: by 10.99.45.195 with SMTP id t186mr9687237pgt.127.1518452556729; Mon, 12 Feb 2018 08:22:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518452556; cv=none; d=google.com; s=arc-20160816; b=dHhOuziyyPM+7xIT2Wl1zEkgY0SMBN2echxIrzpNYtY/xb2fv1KRwQ3JhxJT5NP6ym /quz3xJkXvB3D29AXaLAdwLdFBO/sSnjiCFuah4qjLpzZufjz/iI2bGUtyIiSnQEA+oI EZA3Wy/rJ0eh3qgptkKYRIq8EQF9AjFL0aiwm4PhROAV2HPBibK6fPeldInnCO6gLpwr yL5pfQxx0qbWmaAohrvfEsgtgjHl6UvQV3u1UpTpFO0YNKzM2B7AwSuhdPG/Pdqmrktg 94bjh2kB4ZEW/BH2eOyRbiACOdpA90xgPRNLuepu5yA3hcAYW0zCnYvA9RufvbAKlfIc XkLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=6AwTjNL7xOzRjotRoLthmrDPkues6krVLsJ4BLwDnRA=; b=iZX0PYLyqY0jGf0iS0fbmQXOa/JE2dtLRORXHmIifCu6eOcd6i68jYtwpLD3xBJoAf dy7sXxb/FgZz2aW684R6rOs8b2xC530T+3IuHN+KxU/1X+yzMgxSmoWW4e1O5aerCaO8 bdfn/pYY4PMsKtZp9F6iQRjfLPpPgtaj1kAIYxCXeR3w0WocdqrhiE/p7vIuFEkAv9fY FGj9ql0XLFgjCiGbvVUlmriaWFZyoUXq5CZ3e87dMfvLvdbGuYSu6Zfj3hOw4Fx+olVV wF2YsYGM8VVbDK8App8MJmx6wYH/NCXAG/s0TtikDYibntwbNGUai3nZ9PeNVNP/0n1Z 9Ydg== 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 95-v6si118310plc.397.2018.02.12.08.22.20; Mon, 12 Feb 2018 08:22:36 -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 S964955AbeBLQUC (ORCPT + 99 others); Mon, 12 Feb 2018 11:20:02 -0500 Received: from www.sr71.net ([198.145.64.142]:53760 "EHLO blackbird.sr71.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S964916AbeBLQUB (ORCPT ); Mon, 12 Feb 2018 11:20:01 -0500 X-Greylist: delayed 383 seconds by postgrey-1.27 at vger.kernel.org; Mon, 12 Feb 2018 11:20:00 EST Received: from [0.0.0.0] (50-39-110-205.bvtn.or.frontiernet.net [50.39.110.205]) (Authenticated sender: dave) by blackbird.sr71.net (Postfix) with ESMTPSA id 2A2C4FA862; Mon, 12 Feb 2018 08:13:35 -0800 (PST) Subject: Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware To: Ingo Molnar , hpa@zytor.com, tglx@linutronix.de, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, dwmw@amazon.co.uk, peterz@infradead.org References: <1518362359-1005-1-git-send-email-dwmw@amazon.co.uk> <20180212102211.cdrrqqd4hdw7xu5y@gmail.com> Cc: linux-tip-commits@vger.kernel.org, Borislav Petkov , Arjan van de Ven From: Dave Hansen Message-ID: Date: Mon, 12 Feb 2018 08:13:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180212102211.cdrrqqd4hdw7xu5y@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/2018 02:22 AM, Ingo Molnar wrote: >> +static inline void firmware_restrict_branch_speculation_end(void) >> +{ >> + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0, >> + X86_FEATURE_USE_IBRS_FW); > BTW., there's a detail that only occurred to me today, this enabling/disabling > sequence is not NMI safe, and it might be called from NMI context: FWIW, Tim Chen and I talked about this a bunch. We ended up just saving/restoring the MSR verbatim in the NMI handler the same way we do CR3, stashing it in a high general-purpose-register (r%12?). That costs a RDMSR (at least) and an WRMSR (which you can optimize out). We have a patch for that somewhere if anybody wants it. We also came to the same conclusion that it's a rather challenging thing to exploit these cases, especially when you consider that we can easily do RSB stuffing on NMI exit just before going back to the firmware.