Linux – How does the Linux Kernel handle newer chips that patched only against Spectre Variant 1 but not Variant 2

cpuintellinux-kernelperformancevulnerability

How will chips patched for Spectre Variant 1 and Meltdown, like Whiskey Lake and Amber Lake, handle Spectre Variant 2? I'm looking to spec out a new laptop. Currently evaluating the Lenovo x390. It's set to ship with Whiskey Lake, which claims to have hardware fixes for Meltdown and Spectre Variant 1

According to A Nand Tech

The big performance marker is tackling Spectre Variant 2. When fixed in software, Intel expects a 3-10% drop in performance depending on the workload – when fixed in hardware, Intel says that performance drop is a lot less, but expects new platforms (like Cascade Lake) to offer better overall performance anyway. Neither Whiskey Lake nor Amber Lake have mitigations for v2, but Whiskey Lake is certainly well on its way with fixes to some of the more dangerous attacks, such as v3 and L1TF. Whiskey Lake is also offering new performance bins as the platform is also on 14++, which will help with performance and power.

So my question is if in the new chips (Whiskey Lake and Amber Lake), is anything to be gained in performance by just fixing Spectre Variant 1 and Meltdown? Will the fact that they have hardware patches for just 2/3 CPU vulnerabilities provide anything in hardware for the Kernel to take advantage of? Or will the Linux Kernel apply the same crippling software mitigations to protect against Spectre Variant 2?

Best Answer

This will be an Intel-centric answer.

Note that at the kernel level, the Spectre/Meltdown mitigations are not a single monolithic lump, but each Spectre/Meltdown variant has its own set of mitigations.

Meltdown

The kernel-level mitigation for Meltdown is called Page Table Isolation. The kernel can do it on its own, with a significant performance impact.

It helps if the processor+microcode offers Process Context IDentifiers (PCID), and even more if the INVPCID instruction is available in the processor: the Meltdown-fixing microcode updates added one or both of these capabilities, according to what the microcode could do on each particular processor model. Linux can certainly use these if they're available, and they can significantly reduce the performance impact of Meltdown mitigation.

Of course, the best situation is if the Page Table Isolation is not needed at all, and this is apparently what the "Hardware" fix for Meltdown means.

And if you think your system is secure enough and performance is more important to you, there is an option to turn the Meltdown fix off.

Spectre Variant 1

This is mitigated by patching the compiler to handle pointers more carefully in specific situations, and then rebuilding the kernel (and hypervisor, if any) and any security-critical binaries using the patched compiler. This has been done. It adds some extra instructions to the key locations in the compiled code, which makes programs slightly larger and slower to execute, but fortunately the difference is usually tiny.

As far as I understand, the microcode and the processor design cannot do much here: even Cascade Lake indicates only OS/VMM-level fixes for this.

Spectre Variant 2

This is the tricky one, and probably hardest to fix, as a true fix requires some innovation at the level of CPU design theory.

Even without any assistance from the CPU hardware+microcode, the kernel can implement retpoline, i.e. RETurn instruction trampoline. That is an Assembler-level programming technique. As with the Meltdown mitigation, since implementing this takes a non-trivial chunk out of system performance, you have the option to disable this mitigation of you need performance more than security.

The CPU+microcode can again provide some new features that make the Spectre V2 mitigation easier for the kernel:

Indirect Branch Restricted Speculation (IBRS), basically a switchable mode in the CPU's branch predictor that prevents user-space code from influencing the branch prediction in the kernel-space across the user->kernel mode transition.
Indirect Branch Predictor Barrier (IBPB): basically a new CPU instruction that stops any code before it affecting the branch prediction in the code after the IBPB instruction.
Single Thread Indirect Branch Predictors (STIBP): a way to stop hyper-threads on the same core from sharing branch prediction information.

The Linux kernel can use these features where appropriate, to help minimize the performance loss caused by the retpoline technique.

See this Intel PDF for more details.

Related Solutions

Linux – How does the kernel assign cpu ids to physical cores

Is is hardly documented and largely depends on a platform. For x86, next available id is assigned to CPU in the function generic_processor_info()

So, for x86, cpu ids are depending on order in which we would call that function. It is called when APIC (interrupt controller) is initialized, while APIC settings are taken from ACPI MADT table and the ACPI tables are provided by BIOS.

You may try to decode them yourself using ACPI tools (acpica-tools package in CentOS):

# acpidump > acpi.dat
# acpixtract -a acpi.dat
# iasl -d apic.dat
...
# cat apic.dsl | awk -F: '/Subtable Type/ { st = $2 }
                          /Processor ID/ { id = $2 }
                          /Processor Enabled/ { print id, $2, st } '

Linux – How does the Linux kernel handle keyboards inputs/outputs

See How do keyboard input and text output work? for an overview of the topic.

In more detail, under Linux, the kernel receives scan codes from the hardware and converts them into keycodes. (This terminology isn't completely standard; you may find “scan code” or “key code” used for both.) How this conversion works depends on the keyboard driver. For PS/2 keyboards, you can configure it with setkeycodes. For USB keyboards, you can configure it via udev. See also the Arch wiki. All user input devices, including keyboards and mice, are exposed via event devices /dev/input/event*.

In a Linux console, keycodes are mapped to escape sequences according to the console keymap. Since a console is a text terminal, applications see bytes, with printable characters representing themselves and function keys encoded using control characters or escape sequences. You can change the mapping with loadkeys. The mapping uses two levels of indirection, from keycode+modifier combination (with three modifiers: shift, control, alt) to keysym and from keysym to string (character or escape sequence). The set of keysyms is fixed, so if you want to define custom combinations you'll need to use existing keysyms that aren't otherwise used such as F13, F14, …

If you want to look at the source code that implements these translations, look at keyboard drivers and generic input code, and udev and libudev.

X11 (the GUI) has its own way to map keycodes to what applications receive. X11 applications see keysyms and modifiers, so function keys don't need to be encoded further. There are in fact two ways to define keymaps under X: the classical method xmodmap, and the newer mechanism XKB which is more powerful but more complex.