PROBLEM: # journalctl -b Jun 26 00:55:40 hostname kernel: cgroup: cgroup2: unknown option "nsdelegate" SOLUTION: Stabilize a kernel version >=4.13.xx See also: https://github.com/systemd/systemd/issues/6314 This problem appeared after downgrading sys-kernel/gentoo-sources to 4.9.xx to mitigate the Meltdown/Spectre vulnerabilities. Granted, I could upgrade to an unstable kernel, but I'd rather have a stable one(personal preference) # eselect kernel list Available kernel symlink targets: [1] linux-4.9.72-gentoo [2] linux-4.9.95-gentoo *
# dmesg | grep microcode [ 0.952080] microcode: sig=0x906e9, pf=0x2, revision=0x8e [ 0.952132] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba See: https://github.com/hannob/meltdownspectre-patches sudo ./spectre-meltdown-checker.sh Password: Spectre and Meltdown mitigation detection tool v0.37+ Checking for vulnerabilities on current system Kernel is Linux 4.9.95-gentoo #1 SMP Tue Jun 26 00:44:23 CDT 2018 x86_64 CPU is Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: arcmsr 31195 0 - Live 0xffffffffa020a000 UNKNOWN (is msr kernel module available?) * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: UNKNOWN (is msr kernel module available?) * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit) * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: UNKNOWN (is msr kernel module available?) * CPU indicates STIBP capability: YES (Intel STIBP feature bit) * Speculative Store Bypass Disable (SSBD) * CPU indicates SSBD capability: YES (Intel SSBD) * 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 explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO * CPU microcode is known to cause stability problems: NO (model 0x9e family 0x6 stepping 0x9 ucode 0x8e cpuid 0x906e9) * CPU vulnerability to the speculative execution attack variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES * Vulnerable to Variant 3a: YES * Vulnerable to Variant 4: 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): UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Kernel has the Red Hat/Ubuntu patch: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Kernel has mask_nospec64 (arm): UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Checking count of LFENCE instructions following a jump in kernel... UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) > 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 * IBRS enabled and active: YES (for kernel and firmware code) * Kernel is compiled with IBPB support: YES * 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) * Kernel supports RSB filling: UNKNOWN (kernel image missing) > STATUS: NOT VULNERABLE (IBRS + IBPB are mitigating the vulnerability) 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 * 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) CVE-2018-3640 [rogue system register read] aka 'Variant 3a' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) CVE-2018-3639 [speculative store bypass] aka 'Variant 4' * Kernel supports speculation store bypass: NO > STATUS: VULNERABLE (your kernel needs to be updated) > How to fix: You have a recent-enough CPU microcode but your kernel is too old to use the new features exported by your CPU's microcode. If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel from recent-enough sources. A false sense of security is worse than no security at all, see --disclaimer Notice Variant 4 still reporting VULNERABLE because 4.9.xx is too old.
(In reply to Carter Young from comment #1) > CVE-2018-3639 [speculative store bypass] aka 'Variant 4' > * Kernel supports speculation store bypass: NO > > STATUS: VULNERABLE (your kernel needs to be updated) > > > How to fix: You have a recent-enough CPU microcode but your kernel is too old to use the new features exported by your CPU's microcode. If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel from recent-enough sources. > > A false sense of security is worse than no security at all, see --disclaimer > > Notice Variant 4 still reporting VULNERABLE because 4.9.xx is too old. Variant 4 can be somewhat mitigated using kernel versions >=4.15.xx, see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639 As such, updated title
probably would be better to wait for the needed patches to be backported to 4.14.x instead of stabilizing a non-LTS kernel :/
A non-LTS kernel is hardly going to be stabilized.
If 4.13 is enough, we can just block this a duplicate of 4.14 stabilization request. *** This bug has been marked as a duplicate of bug 649198 ***
(In reply to Tomáš Mózes from comment #5) > If 4.13 is enough, we can just block this a duplicate of 4.14 stabilization > request. > > *** This bug has been marked as a duplicate of bug 649198 *** ... we can just mark this as duplicate of the 4.14 stabilization bug ;)