lkml.org 
[lkml]   [2018]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH V2] x86/speculation: Support Enhanced IBRS on future CPUs
Date
> 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

\
 
 \ /
  Last update: 2018-07-31 06:03    [W:0.149 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site