How to enable IBRS in kernel?

Asked by corrado venturini on 2018-04-13

in: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls
i see: echo 1 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in kernel
but the suggested command returns:
corrado@corrado-p3-bb-0409:~$ echo 1 > /proc/sys/kernel/ibrs_enabled
bash: /proc/sys/kernel/ibrs_enabled: No such file or directory
corrado@corrado-p3-bb-0409:~$ echo 2 > /proc/sys/kernel/ibrs_enabled
bash: /proc/sys/kernel/ibrs_enabled: No such file or directory
corrado@corrado-p3-bb-0409:~$

I'm using Ubuntu Bionic Beta updated daily
corrado@corrado-p3-bb-0409:~$ inxi -SCx
System: Host: corrado-p3-bb-0409 Kernel: 4.15.0-13-generic x86_64
           bits: 64 gcc: 7.3.0
           Desktop: Gnome 3.28.0 (Gtk 3.22.29-3ubuntu1)
           Distro: Ubuntu Bionic Beaver (development branch)
CPU: Dual core Intel Core i3-7100 (-MT-MCP-)
           arch: Skylake rev.9 cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 15648
           clock speeds: max: 3900 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz
           4: 800 MHz
corrado@corrado-p3-bb-0409:~$

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu intel-microcode Edit question
Assignee:
No assignee Edit question
Solved by:
corrado venturini
Solved:
2018-04-13
Last query:
2018-04-13
Last reply:
2018-04-13

What is the output of:

ls /proc/sys/kernel

Thanks

corrado@corrado-p3-bb-0409:~$ ls /proc/sys/kernel
acct pid_max
acpi_video_flags poweroff_cmd
auto_msgmni print-fatal-signals
bootloader_type printk
bootloader_version printk_delay
cad_pid printk_devkmsg
cap_last_cap printk_ratelimit
core_pattern printk_ratelimit_burst
core_pipe_limit pty
core_uses_pid random
ctrl-alt-del randomize_va_space
dmesg_restrict real-root-dev
domainname sched_autogroup_enabled
ftrace_dump_on_oops sched_cfs_bandwidth_slice_us
ftrace_enabled sched_child_runs_first
hardlockup_all_cpu_backtrace sched_domain
hardlockup_panic sched_latency_ns
hostname sched_migration_cost_ns
hotplug sched_min_granularity_ns
hung_task_check_count sched_nr_migrate
hung_task_panic sched_rr_timeslice_ms
hung_task_timeout_secs sched_rt_period_us
hung_task_warnings sched_rt_runtime_us
io_delay_type sched_schedstats
kexec_load_disabled sched_time_avg_ms
keys sched_tunable_scaling
kptr_restrict sched_wakeup_granularity_ns
max_lock_depth seccomp
modprobe sem
modules_disabled sem_next_id
msgmax sg-big-buff
msgmnb shmall
msgmni shmmax
msg_next_id shmmni
ngroups_max shm_next_id
nmi_watchdog shm_rmid_forced
ns_last_pid softlockup_all_cpu_backtrace
numa_balancing softlockup_panic
numa_balancing_scan_delay_ms soft_watchdog
numa_balancing_scan_period_max_ms stack_tracer_enabled
numa_balancing_scan_period_min_ms sysctl_writes_strict
numa_balancing_scan_size_mb sysrq
osrelease tainted
ostype threads-max
overflowgid timer_migration
overflowuid traceoff_on_warning
panic tracepoint_printk
panic_on_io_nmi unknown_nmi_panic
panic_on_oops unprivileged_bpf_disabled
panic_on_rcu_stall unprivileged_userns_apparmor_policy
panic_on_unrecovered_nmi unprivileged_userns_clone
panic_on_warn usermodehelper
perf_cpu_time_max_percent version
perf_event_max_contexts_per_stack watchdog
perf_event_max_sample_rate watchdog_cpumask
perf_event_max_stack watchdog_thresh
perf_event_mlock_kb yama
perf_event_paranoid
corrado@corrado-p3-bb-0409:~$

sorry, previous list was incomplete.
.
corrado@corrado-p3-bb-0409:~$ ls /proc/sys/kernel
acct pid_max
acpi_video_flags poweroff_cmd
auto_msgmni print-fatal-signals
bootloader_type printk
bootloader_version printk_delay
cad_pid printk_devkmsg
cap_last_cap printk_ratelimit
core_pattern printk_ratelimit_burst
core_pipe_limit pty
core_uses_pid random
ctrl-alt-del randomize_va_space
dmesg_restrict real-root-dev
domainname sched_autogroup_enabled
ftrace_dump_on_oops sched_cfs_bandwidth_slice_us
ftrace_enabled sched_child_runs_first
hardlockup_all_cpu_backtrace sched_domain
hardlockup_panic sched_latency_ns
hostname sched_migration_cost_ns
hotplug sched_min_granularity_ns
hung_task_check_count sched_nr_migrate
hung_task_panic sched_rr_timeslice_ms
hung_task_timeout_secs sched_rt_period_us
hung_task_warnings sched_rt_runtime_us
io_delay_type sched_schedstats
kexec_load_disabled sched_time_avg_ms
keys sched_tunable_scaling
kptr_restrict sched_wakeup_granularity_ns
max_lock_depth seccomp
modprobe sem
modules_disabled sem_next_id
msgmax sg-big-buff
msgmnb shmall
msgmni shmmax
msg_next_id shmmni
ngroups_max shm_next_id
nmi_watchdog shm_rmid_forced
ns_last_pid softlockup_all_cpu_backtrace
numa_balancing softlockup_panic
numa_balancing_scan_delay_ms soft_watchdog
numa_balancing_scan_period_max_ms stack_tracer_enabled
numa_balancing_scan_period_min_ms sysctl_writes_strict
numa_balancing_scan_size_mb sysrq
osrelease tainted
ostype threads-max
overflowgid timer_migration
overflowuid traceoff_on_warning
panic tracepoint_printk
panic_on_io_nmi unknown_nmi_panic
panic_on_oops unprivileged_bpf_disabled
panic_on_rcu_stall unprivileged_userns_apparmor_policy
panic_on_unrecovered_nmi unprivileged_userns_clone
panic_on_warn usermodehelper
perf_cpu_time_max_percent version
perf_event_max_contexts_per_stack watchdog
perf_event_max_sample_rate watchdog_cpumask
perf_event_max_stack watchdog_thresh
perf_event_mlock_kb yama
perf_event_paranoid
corrado@corrado-p3-bb-0409:~$

Manfred Hampl (m-hampl) said : #4

Can you run the spectre-meltdown-checker on that system and verify the value shown for
* CPU indicates IBRS capability
* Kernel is compiled with IBRS/IBPB support

I do not know any details, but it might be the case that i3- family CPUs do not (yet) have that feature.
See page 9 in https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf

I ask this question because spectre-meltdown-checker says
...
  * Kernel is compiled with IBRS support: YES (found IBRS_FW in sysfs)
    * IBRS enabled and active: YES (for firmware code)
  * Kernel is compiled with IBPB support: YES (IBPB found enabled in sysfs)
    * IBPB enabled and active: YES
* Mitigation 2
...
> How to fix: Both your CPU and your kernel have IBRS support, but it is currently disabled. You may enable it. Check in your distro's documentation on how to do this.

corrado@corrado-p3-bb-0409:~$ sudo ./spectre-meltdown-checker.sh -v
[sudo] password for corrado:
Spectre and Meltdown mitigation detection tool v0.36+

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-13-generic #14-Ubuntu SMP Sat Mar 17 13:44:27 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz
Will use kernel image /boot/vmlinuz-4.15.0-13-generic.efi.signed
Will use kconfig /boot/config-4.15.0-13-generic
Will use System.map file /proc/kallsyms
Kernel image is Linux version 4.15.0-13-generic (buildd@lgw01-amd64-023) (gcc version 7.3.0 (Ubuntu 7.3.0-11ubuntu1)) #14-Ubuntu SMP Sat Mar 17 13:44:27 UTC 2018 (Ubuntu 4.15.0-13.14-generic 4.15.10)

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available: YES
    * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates STIBP capability: YES (Intel STIBP feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
  * CPU microcode is known to cause stability problems: NO (model 158 stepping 9 ucode 0x84 cpuid 0x906e9)
* CPU vulnerability to the three speculative execution attack variants
  * Vulnerable to Variant 1: YES
  * Vulnerable to Variant 2: YES
  * Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86): YES (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm): NO
* Checking count of LFENCE instructions following a jump in kernel... NO (only 7 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
  * Kernel is compiled with IBRS support: YES (found IBRS_FW in sysfs)
    * IBRS enabled and active: YES (for firmware code)
  * Kernel is compiled with IBPB support: YES (IBPB found enabled in sysfs)
    * IBPB enabled and active: YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm): NO
  * Kernel compiled with retpoline option: YES
    * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
    * Local gcc is retpoline-aware: NO (gcc is not installed)
> STATUS: VULNERABLE (IBRS+IBPB is needed to mitigate the vulnerability)

> How to fix: To mitigate this vulnerability, you need IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support. The retpoline approach doesn't work on your CPU, as this is a Skylake+ model.

> How to fix: Both your CPU and your kernel have IBRS support, but it is currently disabled. You may enable it. Check in your distro's documentation on how to do this.

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
  * PTI enabled and active: YES
  * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer
corrado@corrado-p3-bb-0409:~$

I found the answer in https://github.com/speed47/spectre-meltdown-checker/issues/178

Thanks for the details. Apparently recent Ubuntu kernels have dropped the "Red Hat" patch (that allows use of complete IBRS, not only in firmware as this is the case here), and are now acting like upstream.
For Skylake, they rely on retpoline + IBPB + RSB stuffing. I have to implement detection of proper RSB filling, expect a commit about this sometime during the weekend ;)

reference: https://elixir.bootlin.com/linux/v4.16.2/source/arch/x86/kernel/cpu/bugs.c#L286

so my question is solved even if the original problem is still open
thanks