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;
From:   "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
To:     Thomas Gleixner <tglx@linutronix.de>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "Chen, Tim C" <tim.c.chen@intel.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        Ingo Molnar <mingo@kernel.org>
Subject: RE: [PATCH V2] x86/speculation: Support Enhanced IBRS on future CPUs
Thread-Topic: [PATCH V2] x86/speculation: Support Enhanced IBRS on future
 CPUs
Thread-Index: AQHUKDpXeyPtJ37V00Gaz4M9pA51zKSotaGA///0qMA=
Date:   Tue, 31 Jul 2018 04:03:01 +0000
Message-ID: <FFF73D592F13FD46B8700F0A279B802F4757790C@ORSMSX114.amr.corp.intel.com>
References: <1532978396-2197-1-git-send-email-sai.praneeth.prakhya@intel.com>
 <alpine.DEB.2.21.1807302153570.1725@nanos.tec.linutronix.de>
In-Reply-To: <alpine.DEB.2.21.1807302153570.1725@nanos.tec.linutronix.de>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> There is no reason not to use indentation and quotation marks in a changelog.
> Squeezing it into square brackets does not really improve readability.
> 
>  From the specification [1]:
> 
>   "With enhanced IBRS, the predicted targets of indirect branches executed
>    cannot be controlled by software that was executed in a less privileged
>    ....
>    to entering a sleep state such as MWAIT or HLT."
> 
> Hmm?

Yes, this looks good. I have changed commit message in V3 accordingly.

> > x86_spec_ctrl_set_guest() before entering guest and
> > x86_spec_ctrl_restore_host() after leaving guest. So, the guest view
> > of SPEC_CTRL MSR is restored before entering guest and the host view
> > of SPEC_CTRL MSR is restored before entering host and hence IBRS will
> > be set after VMEXIT.
> 
> What you are trying to say here is:
> 
>  If Enhanced IBRS is selected as mitigation mechanism the IBRS bit is set  once at
> boot time and never cleared. This also has to be ensured after a  VMEXIT
> because the guest might have cleared the bit. This is already  covered by the
> existing x86_spec_ctrl_set_guest() and
>  x86_spec_ctrl_restore_host() speculation control functions.
> 
> Hmm?

Yes, that's correct. It's simple and concise. I have updated commit message as suggested.

> 
> > Intel's white paper on Retpoline [2] says that "Retpoline is known to
> > be an effective branch target injection (Spectre variant 2) mitigation
> > on Intel processors belonging to family 6 (enumerated by the CPUID
> > instruction) that do not have support for enhanced IBRS. On processors
> > that support enhanced IBRS, it should be used for mitigation instead
> > of retpoline."
> >
> > This means, Intel recommends using Enhanced IBRS over Retpoline where
> > available and it also means that retpoline provides less mitigation on
> > processors with enhanced IBRS compared to those without.
> 
> The cited part of the white paper does not say that its a broader mitigation than
> what Retpoline covers. It merely recommends to use enhanced IBRS without
> providing a reason.
> 
> But chapter 4.3 contains the real reason for using Emhanced IBRS: The
> processors which support it also support CET and CET does not work well with
> Retpoline.
> 
> Please provide facts and not interpretations.

Sorry! got it.

> If you have additional knowledge
> about a broader mitigation scope, then clearly say so:
>

Hmm.. no.. not really. I just learned it from Dave.

> > Hence, on processors that support Enhanced IBRS, this patch makes
> > Enhanced IBRS as
> 
> Please search Documentation/process/submitting-patches.rst for 'This patch' ....
> 

Yes, got it. Will refrain myself from using 'This patch' further.

>  The reason why 'Enhanced IBRS is the recommended mitigation on processors
> which support it is that these processors also support CET which provides  a
> defense against ROP attacks. Retpoline is very similar to ROP techniques  and
> might trigger false positives in the CET defense.
> 
>  Enhanced IBRS still requires IBPB for full mitigation.
> 
> See? You might have noticed that aside of restructuring and enhancing the
> information I also got rid of all 'we' instances. Using 'we' is a form of
> impersonation which IMO blurs the technicality of a changelog.

Makes sense. Will stop using 'we' further.

> 
> 
> > [1]
> > https://software.intel.com/sites/default/files/managed/c5/63/336996-Sp
> > eculative-Execution-Side-Channel-Mitigations.pdf
> > [2]
> > https://software.intel.com/sites/default/files/managed/1d/46/Retpoline
> > -A-Branch-Target-Injection-Mitigation.pdf
> 
> These links are not really useful as sooner than later they are going to be invalid.
> We recently started to put copies of such documents into the kernel.org bugzilla
> and I'm pretty sure we have at least one of them already in one of the
> speculation mess related BZs. Could you please track that down and make sure
> that both files are available there in the latest version. Then provide links to the
> BZ entry which are more likely to survive than content on a corporate website.
>

Sure! Makes sense.
I have updated Bugzilla link that has these documents and also updated commit message in V3.

> > @@ -219,6 +219,7 @@
> >  #define X86_FEATURE_IBPB		( 7*32+26) /* Indirect Branch
> Prediction Barrier */
> >  #define X86_FEATURE_STIBP		( 7*32+27) /* Single Thread Indirect
> Branch Predictors */
> >  #define X86_FEATURE_ZEN			( 7*32+28) /* "" CPU is AMD
> family 0x17 (Zen) */
> > +#define X86_FEATURE_IBRS_ENHANCED		( 7*32+29) /*
> "ibrs_enhanced" Use Enhanced IBRS in kernel */
> 
> That "ibrs_enhanced" part is not needed.

Just wanted to confirm with you before removing it, 
Presently, on platforms that support features like arch_capabilities, stibp, ibrs and ibpb 
/proc/cpuinfo does show them. Do you think we should really skip showing 
Enhanced IBRS capability?

> And 'Use' is also wrong. The feature
> merily reflects the availability of Enhanced IBRS and not its usage.
> 

Makes sense. Updated comment in V3.

> > +	/*
> > +	 * As we don't use IBRS in kernel, nobody should have set
> > +	 * SPEC_CTRL_IBRS until now. Shout loud if somebody did enable
> > +	 * SPEC_CTRL_IBRS before us.
> > +	 */
> 
> This comment does not make sense. What prevents the BIOS/bootloader or the
> hypervisor from setting it?
>

Makes sense. Removed it from V3.

> > +	WARN_ON_ONCE(x86_spec_ctrl_base & SPEC_CTRL_IBRS);
> > +
> > +	/* Ensure SPEC_CTRL_IBRS is set after VMEXIT from a guest */
> > +	x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
> 
> And what exactly writes the MSR?
>

While booting, x86_spec_ctrl_setup_ap() does that and after VMEXIT 
x86_spec_ctrl_restore_host().

As x86_spec_ctrl_setup_ap() does wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base), 
I thought writing here would be redundant.

Did I answer your question or did I get it wrong?

Regards,
Sai