Hi, For AMD, IBRS is available for architectures before Zen with a microcode update. On K17, only IBPB (branch prediction barrier) exists (after a microcode update too)…
And yeah, I expect IBRS to be possible to work around in the future… On Windows, IBRS is forced anyway after the BIOS/UEFI has the new microcode and on Red Hat Enterprise Linux too... IBRS is supposed to be faster on Skylake and later, but I really don't know if it's just an Intel lie at this point (wouldn't be the first one on this fiasco... maybe they just want to avoid a recall) Thanks, From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Dillon Sent: Monday, January 8, 2018 11:34 PM To: my123 (@never_released) <[email protected]> Cc: [email protected] Subject: Re: Clarifying the Spectre mitigations... IBRS in mode 2 (i.e. always leaving it on) results in a 30%+ performance hit to everything, at least on older cpus. This is not a complete mitigation either, it's really just a bad microcode hack by Intel that nobody really wants to have to turn on. IBRS in mode 1 (i.e. just during kernel execution and not during user execution) will significantly impact anything that uses the kernel heavily, such as the network stack. This mode will not protect against the most common like Spectre attack (which is a javascript attack against the browser it is running it). RetPoline is only a partial mitigation. MMU isolation + IBRS mode 2 increases system call overhead to over 800nS. -- In terms of DragonFlyBSD, MMU isolation is now built into master. IBRS and RetPoline are not, yet. I'm still evaluating them, and in fact for IBRS (aka Spectre Attacks) it isn't just Intel, but AMD is also doing a microcode update and I have no information on their implementation yet. It is possible to run DragonFlyBSD with mode 2 IBRS right now by installing the appropriate microcode update from Intel using cpucontrol, and turn IBRS on with cpucontrol MSR ops. But my recommendation is that people not try to shortcut Specter protections... wait until we finish evaluating it and get something in the system. I'll be honest... I personally do not think there is a viable protection against Spectre possible on Intel, even with the microcode IBRS stuff. Turning on the best possible mitigation (IBRS mode 2) destroys the performance of the machine across all applications and use cases. If you want to play with IBRS mode 2: * I found a microcode archive at https://launchpad.net/ubuntu/+source/intel-microcode/3.20171215.1 (I don't know if it is the latest one) kldload cpuctl pkg install devcpu-data unpack the tar archive and move the *.fw files into /usr/local/share/cpucontrol/ See if you can apply the microcode updates: cpucontrol -u /dev/cpuctl0 cpucontrol -u /dev/cpuctl1 cpucontrol -u /dev/cpuctl2 cpucontrol -u /dev/cpuctl3 ... for all cpu cores (hyperthreads will be ignored) See if there is IBRS support: test40# cpucontrol -i 7,0 /dev/cpuctl0 (BEFORE MICROCODE UPDATE) cpuid level 0x7, level_type 0x0: 0x00000000 blah 0x00000000 0x00000000 test40# cpucontrol -i 7,0 /dev/cpuctl0 (AFTER MICROCODE UPDATE) cpuid level 0x7, level_type 0x0: 0x00000000 blah 0x00000000 0x0c000000 If you get the 0C in the last word, there is IBRS support. You can try turning it on with cpucontrol. cpucontrol -m 48=1 /dev/cpuctl0 .... do for all cpus ... That is 95% of IBRS mode 2. But be prepared for a performance implosion. Also, Intel might not have a microcode update for whatever cpu you are on yet (or ever). -Matt On Sun, Jan 7, 2018 at 5:23 AM, my123 (@never_released) <mailto:[email protected]> wrote: Hi, The kernel is protected against Spectre with retpoline but application-specific patches are required except when IBPB=2 + STIBP, IBRS=1 + IBPB=1, or IBRS=2 are used. IBPB is a branch prediction barrier that solves Spectre on its maximum setting, but it comes with a performance hit. It requires enabling STIBP for full protection too, except when hyperthreading is disabled. IBRS is the restricted indirect branch speculation feature, which solves Spectre on its maximum setting, except for VM isolation but requires a performance hit too. In order to protect virtual machines from other virtual machines, ibpb=1 is needed even if ibrs is set to 2.. IBPB=1 *and* IBRS=1 works too but it causes a performance hit, and IBRS=2 + IBPB=1 is needed for isolation between virtual machines, but isn't required when VMs aren't used. AMD implements IBRS and IBPB for CPU families before 17h (Zen), but only IBPB and STIBP for Zen. All those features require newer microcode to work... and the impact on performance is not zero. The alternative is recompiling every sensitive thing with retpoline... which is what Linux is trying to implement on mainline. On Windows, as convincing developers to update their toolchain is hard there, IBRS and IBPB are used there despite the performance hit. Hoping that I made things a bit clearer...
