On Mon, Jan 08, 2018 at 05:14:37PM +0100, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote: > > > a good suggestion, but we encountered some issues with it either > > > crashing the kernel at boot or not properly turning on/off. > > The below boots, but I lack stuff to test the enabling.
..snip.. > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -373,22 +373,17 @@ For 32-bit we have the following convent > .endm > > .macro ENABLE_IBRS > - testl $1, dynamic_ibrs > - jz .Lskip_\@ > + STATIC_JUMP_IF_FALSE .Lskip_\@, ibrs_key, def=0 > > PUSH_MSR_REGS > WRMSR_ASM $MSR_IA32_SPEC_CTRL, $SPEC_CTRL_FEATURE_ENABLE_IBRS > POP_MSR_REGS > - jmp .Ldone_\@ > > .Lskip_\@: > - lfence > -.Ldone_\@: > .endm I know that this particular patchset is now obsolete as the retpoline along with stuffing the RSB half or full is the preferred way. But I am wondering - why was the 'lfence' added in the first place if dynamic_ibrs was zero? It certainly is not putting the speculative execution on a wild ride like: "[tip:x86/pti] x86/retpoline: Use LFENCE instead of PAUSE in the retpoline/RSB filling RSB macros" https://git.kernel.org/tip/2eb9137c8744f9adf1670e9aa52850948a30112b So what was the intent behind this? Was it: "oh if we do not have IBRS let us at least add lfence on every system call, interrupt, nmi, exception, etc to do a poor man version of IBRS?" Thank you. P.S. My apologies if this was discussed in the prior versions of this thread. I must have missed it.
