CybserSecurity News

Tag: Linux Kernel 4.20

  • Linux kernel 4.20 reached End-of-Life, Linux kernel 5.0 is recommended

    Greg Kroah-Hartman, a well-known Linux kernel developer and maintainer, announced today that the Linux Kernel 4.20 kernel branch has ended and urges users to upgrade to the updated kernel 5.0 as soon as possible. Linux Kernel 4.20 was released on December 23, 2018, introducing a number of enhancements that fix Indirect Branch Prediction Barrier (IBPB) and Single Thread Indirect Branch Predictors (STIBP) issues, migrating the impact of Spectre exploits.

    Linux Kernel 4.18

    The Linux Kernel 4.20 update provides better Spectre Variant 2 userspace-userspace protection, enhanced Spectre Variant 4 mitigation for ARM64 (AArch64) processors, support for AMD Radeon Pro Vega 20 graphics, support for C-SKY CPU architecture, and Support for Hygon Dhyana x86 CPU, AMD Radeon Picasso, and Raven 2 GPUs.

    With the release of the Linux Kernel 4.20.17 maintenance release, the Linux 4.20 kernel has reached the end of its life and there are no subsequent maintenance releases in the future. Greg strongly recommends that users upgrade to the latest Linux 5.0 kernel branch.

    Greg Kroah-Hartman wrote,

    I’m announcing the release of the 4.20.17 kernel.

    Note, this is the LAST release of the 4.20.y kernel. It is now
    end-of-life, please move to the 5.0.y kernel tree at this point in time.

    All users of the 4.20 kernel series must upgrade.

  • Linus Torvalds is not satisfied with Linux Kernel 4.20 performance degradation

    Phoronix recently found that on almost all low-end, high-end Intel processors, the latest beta kernel, Linux Kernel 4.20, has a significant performance degradation over the latest stable version 4.19, while AMD’s processors are not affected. The reason for the performance degradation is related to Intel processor vulnerability patching. The main change in 4.20 is that STIBP is enabled by default for Intel-supported Hyper-Threading processors to prevent cross-thread control of indirect branch predictors.

    Linus Torvalds was surprised by the fact that he said on the mailing list that he did not see any words that would affect performance in the discussion list. When performance drops by 50% under certain loads, you should first ask if it is worthwhile, not regardless.

    This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was.

    When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It’s apparently better to just disable SMT entirely, which is what security-conscious people do anyway.

    So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?

    I think we should use the same logic as for L1TF: we default to something that doesn’t kill performance. Warn once about it, and let the crazy people say “I’d rather take a 50% performance hit than worry about a theoretical issue”.

    Linus