svn commit: r328625 - in head/sys: amd64/amd64 amd64/ia32 amd64/include dev/cpuctl i386/i386 x86/include x86/x86

[Rodney W. Grimes]

> On Wed, Jan 31, 2018 at 02:56:24PM +0000, Bjoern A. Zeeb wrote:
> > On 31 Jan 2018, at 14:36, Konstantin Belousov wrote:
> > 
> > > Author: kib
> > > Date: Wed Jan 31 14:36:27 2018
> > > New Revision: 328625
> > > URL: https://svnweb.freebsd.org/changeset/base/328625
> > >
> > > Log:
> > >   IBRS support, AKA Spectre hardware mitigation.
> > 
> > >   For existing processors, you need a microcode update which adds IBRS
> > >   CPU features, and to manually enable it by setting the 
> > > tunable/sysctl
> > >   hw.ibrs_disable to 0.  Current status can be checked in sysctl
> > >   hw.ibrs_active.  The mitigation might be inactive if the CPU feature
> > 
> > Can you change the tunable/sysctl to hw.ibrs_enable[d] (and toggle the 
> > default setting along).
> This is done consistently with the hw.clflush_disable.
> Anyway, the intent is that the knob will be used for disabling,
> since defaults are going to be changed in the near future.

I thought we had something some place that said negative assertions
should be avoided if possible.  

> > I find it highly confusing to have two different sysctls ???disable??? 
> > and ???active??? and a lot
> > of people (and cultures) have trouble with the double negative.
> > Also the ???enable[d]??? variant seems to be pre-dominant in the kernel.
> > 
> > Also can we spell IBRS in the sysctl description as ???Indirect Branch 
> > Restricted Speculation (IBRS)????
> Will do in half a hour.


-- 
Rod Grimes                                                 rgrimes at freebsd.org