From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBouCJlem5Z58Dhg7Y8Fbs5C/zYmjO17Csigmz3qqaCLA1Op8WnwUouS1ttwc8Iu3C9yHB638 ARC-Seal: i=1; a=rsa-sha256; t=1516295569; cv=none; d=google.com; s=arc-20160816; b=Hcuq0dGYt9mY7JfNhuYUmuq7CB1c1gJo+IbZSzp23ESid75+uekWi51lAojjOnMrvh DvRomij2Dst557JgphvtKBGOTKkNfr4UjCON/M3PEGMvlLtqdw0/ouDwFntzxUut0eTd XlX0NHl7WXSCsfHM5FERZCqJwhVvf4Dycsz5NOi5I4rwIjQfIdYrVoPmXpV5fBQ0rlJI mJ/1DxqntNcuuW2oNWP3XBgAKGd1oG0L/hGZdBVCOD7kVsr0IrK4cINW8xKsdNJqwJ8q G5Uw2F7QmNcywIpadOtnxRv7zMGMHBfDlezhS5ao8ZveYFD0lKsZwT4Erd+6BND6WC+O IIAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=dMzzePKdl4xpGZilbGRvkcsMEqRuVZ4HQH8SYDESHk4=; b=zXwHJwbHmyEH5suXhCykjH2S61mA3VPhxOuw0YA6outvt1py+19VO4Vc56nksURdpP wswDwR9ckk1T2QIz6biV/nHwMg9JI2XcNX8glv4G5fBOkT6BsQ9uX9nEyGrX/LroZdZt QFNL3irHuaJtj19Kgab0QHt64SJin0Z1RdzAn6I/1loSxuJSqXWvvGiF3Lgs1G7yCnIl 8kmepW4++EoJLKILwx/xm84uvT9V/L5fHldhkmjOkEb4sWzoj5P2R11ldkCO15CgPMCG bYw4RlPhCXIgKlCE2pavx6GCx1NY7y6CYcsm1sv+FkKPYNLjucJq9BAuZ8+lFoggCLua xpQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code To: Dave Hansen , Josh Poimboeuf , Peter Zijlstra Cc: David Woodhouse , Thomas Gleixner , linux-kernel@vger.kernel.org, Ashok Raj , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Dan Williams , Jun Nakajima , Asit Mallick , Jason Baron References: <20180118134800.711245485@infradead.org> <20180118140152.830682032@infradead.org> <20180118163745.t5nmwdr53wjsl7o5@treble> <73a5735a-6a5b-0e0f-1f0b-e7cd955880d2@intel.com> From: Paolo Bonzini Message-ID: Date: Thu, 18 Jan 2018 18:12:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <73a5735a-6a5b-0e0f-1f0b-e7cd955880d2@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcSW1wb3J0YW50Ig==?= X-GMAIL-THRID: =?utf-8?q?1589948948566960870?= X-GMAIL-MSGID: =?utf-8?q?1589951142540574003?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 18/01/2018 18:08, Dave Hansen wrote: > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: >>> >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -3932,6 +3932,7 @@ >>> retpoline - replace indirect branches >>> retpoline,generic - google's original retpoline >>> retpoline,amd - AMD-specific minimal thunk >>> + ibrs - Intel: Indirect Branch Restricted Speculation >> Are there plans to add spectre_v2=ibrs_always to prevent SMT-based >> attacks? > > What does "ibrs_always" mean to you? > > There is a second bit in the MSR (STIBP) that is intended to keep > hyperthreads from influencing each-other. That is behavior is implicit > when IBRS is enabled. Yeah, I think we should have a mode to always leave that enabled, or always set IBRS=1. > I think ibrs_always *should* probably be kept to refer to the future > CPUs that can safely leave IBRS enabled all the time. Is that "safely" or "without throwing performance down the drain"? Does "always IBRS=1" *hinder* the mitigation on existing processor, as long as you reset IBRS=1 on kernel entry and vmexit? Or is it just slow? Paolo