On Thursday, 18 July 2019 13:33:36 BST Corbin wrote: > On 7/17/19 3:51 PM, Ian Zimmerman wrote: > > pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode > > update is applied pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on > > older processors that can disable indirect branch prediction without > > microcode updates > > > > Note: A microcode patch provided by the vendor must be applied in > > order for the tunables to be visible.> > > which of course is self-contradictory, so not a full answer but maybe a > > clue. I did read this but wasn't sure what to deduce from it. I took it to mean earlier CPUs won't receive a microcode patch, but will still have spectre mitigated, presumably using a different method. Later CPUs will receive a patch. My AMD APUs are later fam15h models and if the above is to be believed they probably ought to have received a patch - but none is observable. :-/ Then I thought the note in the RHL article may need to be taken literally, to mean a microcode patch will just make tunables *visible*, rather than present. > > Are those settings meant to go on a boot command line? > > As for what Red Hat / Fedora is doing, no idea. > > The parameters I used came from the kernel documentation. > > > Corbin According to kernel-4.19.57 docs at least, all CPU vulnerabilities and spectre related mitigations are automatically switched on, without the need to specify anything on the kernel line. In addition, the selection of individual spectre_v2 mitigation methods is determined dynamically "... at run time according to the CPU, the available microcode, the setting of the CONFIG_RETPOLINE configuration option, and the compiler with which the kernel was built." Anyway, selecting 'spectre_v2=on' "... will also enable the mitigation against user space to user space task attacks", so this is a useful option to use. Regarding ibpb not being displayed under my /sys fs the docs say: Default mitigation: If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" Therefore, I am not sure if ibpb is meant to show up unless it has been specified on the kernel line as a spectre_v2_user mitigation method. -- Regards, Mick