Is LTS 4.9.79 patched for spectre

[MrEen]

Yes

[michael louwe]

@ deepakdeshp, .......

If we install any kernel and it doesn't work out, we can always fall back to the old kernel in recovery mode.
Is there any way unknowingly or knowingly to Bork the system due to a new kernel?

.
Mainline/upstream kernels from Linus Torvald/kernel.org are the first to get patched for Meltdown and Spectre, eg kernel 4.15 has the Retpoline feature for Spectre 2. Afterwards, downstream kernels are then patched by the Linux distro developers, eg Ubuntu developers are presently testing the Retpoline feature on Ubuntu kernel 4.13.33, 4.4.113 and 3.13.142.
... Similarly, new kernels are first released by Linus/kernel.org every 2 to 3 months. Afterwards, the new kernel is then adopted and adapted by Linux distros. Bleeding-edge Rolling releases like Fedora will be quicker to adopt the new kernels from Linus/kernel.org, compared to Stable/LTS releases like LM.
... In general, Linux users should run whatever kernel that has been adopted and adapted or recommended by their Linux distro, and not directly from Linus Torvald/kernel.org.

Bear in mind that the Linux distros only support their own adopted kernels, wrt security updates and bug fixes, ie they do not support mainline/upstream kernels.

Tech-geeks who do not want to wait for their Linux distro developers can opt to install kernel 4.15 directly from kernel.org and also install the required compiler, eg GCC 7.0, in order to have the Retpoline feature for Spectre 2. Whether this is enough to be fully patched is debatable, eg do the installed repositories and preinstalled programs need to be recompiled or updated for Retpoline also.?
... Once their Linux distro has incorporated the Retpoline feature into their kernels, the tech-geeks should downgrade to the patched kernels of their Linux distro, eg likely Ubuntu's kernels 4.13.33, 4.4.113 and 3.13.142. Otherwise, running a Linux distro long term on the kernel 4.15 may eventually bork the system. Also, kernel 4.15 will likely not be supported by their Linux distro.

[deepakdeshp]

@ Marziano, .......

That's exactly what I did, taking my liberty to choose what kernel to use, using this very handy tool for installing kernel 4.15 the very day it was released, and my system is no less unstable or unreliable than before. What's more, while waiting for the supported kernels to get patched for Spectre 2, I can be running one which is already patched. At least partially, since my CPU won't be receiving any firmware update any time soon, if ever.

http://news.softpedia.com/news/linux-ke ... 9579.shtml (28 Jan 2018 - Linux Kernel 4.15 Officially Released, Includes Patches for Meltdown and Spectre)

"It is worth pointing out that it's not like we're "done" with spectre/meltdown. There is more work pending (arm, spectre-v1, misc details), and perhaps equally importantly, to actually get the biggest fix for the indirect branch mitigations, you need not just the kernel updates, you need to have a compiler with support for the "retpoline" indirect branch model," says Linus Torvalds in the mailing list announcement.

I still feel that your system can't be borked as you can always revert to the older kernel in grub in recovery mode if the new kernel you added doesn't work for you.

[Pjotr]

If we install any kernel and it doesn't work out, we can always fall back to the old kernel in recovery mode.
Is there any way unknowingly or knowingly to Bork the system due to a new kernel?

Borking the system is perhaps the wrong expression, if you know how to boot from an older kernel. Although there are the things that were pointed out by MrEen (corrupted BIOS) and thx-1138 (data corruption).

But in any case: losing important work because of an unstable/unreliable kernel will always remain a risk.

[michael louwe]

@ deepakdeshp, .......

If we install any kernel and it doesn't work out, we can always fall back to the old kernel in recovery mode.
Is there any way unknowingly or knowingly to Bork the system due to a new kernel?

I still feel that your system can't be borked as you can always revert to the older kernel in grub in recovery mode if the new kernel you added doesn't work for you.

.
There have been rare cases of buggy kernel upgrades/updates completely borking the system = unable to revert to the older kernel or restore with Timeshift = requiring a reinstall.
... There is a definite risk in running LM/Ubuntu on an unsupported mainline/upstream kernel and not on an LTS Ubuntu kernel, wrt the Meltdown and Spectre kernel patches.
.

http://news.softpedia.com/news/linux-ke ... 9215.shtml (4 Jan 2018)

The Linux kernels 4.14.11, 4.9.74, 4.4.109, 3.16.52, 3.18.91, and 3.2.97 kernels are now available to download from the kernel.org website, and users are urged to update their GNU/Linux distributions to these new versions if they run any of those kernel series immediately. Why update? Because they apparently patch a critical vulnerability called Meltdown.

Following suit, on 9 Jan 2018, Ubuntu adapted the above kernel updates from kernel.org and released their own Meltdown/KPTI patch for Ubuntu kernels 4.13.25, 4.4.108 and 3.13.139.

It would not have been good practice for LM/Ubuntu users to download and install those kernels from kernel.org on 4 Jan 2018, ie not wait for Ubuntu's patched kernels on 9 Jan 2018.

According to http://news.softpedia.com/news/linux-ke ... 9579.shtml (28 Jan 2018 - As expected, Linus Torvalds announced today the release of the Linux 4.15 kernel series, the first to be fully patched against the Meltdown and Spectre security vulnerabilities.) , Linus Torvald/kernel.org are just beginning to incorporate the Retpoline feature into their latest released Linux kernel 4.15 series, ie the Retpoline feature has not gone mainstream yet in kernel.org.
... So, it will also take some time before the Retpoline feature will arrive in Ubuntu kernels, ie likely for impending kernels 4.13.33, 4.4.113 and 3.13.142. Again, it is not good practice for LM/Ubuntu users to install kernel 4.15 from kernel.org and not wait for Ubuntu's patched kernels.
... Linux kernel 4.15 is very new and bleeding edge = a dangerous or risky update/upgrade = may bork some computers, especially older computers. But kernel 4.15 may be needed by those running very new computers, eg 8th-gen CPUs.

[deepakdeshp]

As per the advise of experts like Michael and Pjotr, I will start using the kernels in Ubuntu repositories.

However, I used UKUU extensively so far and havnt faced any problems.The problems have been of non supported hardware, which were overcome by booting up the working kernel in recovery mode.

[Sir Charles]

Yes

The said bug in https://bugs.launchpad.net/ubuntu/+sour ... ug/1734147 was reported by 139 persons and mostly affected some Lenovo, Acer and Toshiba computers running Ubuntu 17.10. The bug was fixed by installing the 4.15 and taking some additional steps.

Since the buggy kernel (14.13.0.21) is still in the Mint's repositories, I just wonder why? Or was the bug fixed by Mint and then the fix went upstream?

Kernels_001.png

[smurphos]

the buggy kernel (14.13.0.21) is still in the Mint's repositories, I just ask myself why? Or was the bug fixed by Mint and then the fix went upstream?

Still in Ubuntu's repos - kernels come directly from http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages

Edit to add - I think 14.13.0.21 was the fixed kernel - it's the 4.13.0.19 kernel prior that had the faulty driver enabled. Still in the repos though.

Code: Select all

steve@steve-HP-Pavilion-g6-Notebook-PC ~ $ apt show linux-image-4.13.0-21-generic
Package: linux-image-4.13.0-21-generic
Version: 4.13.0-21.24~16.04.1
Priority: optional
Section: kernel
Source: linux-hwe-edge
Origin: Ubuntu
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 72.0 MB
Provides: aufs-dkms, fuse-module, ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, spl-modules, virtualbox-guest-modules, zfs-dkms, zfs-modules
Depends: kmod
Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo, initramfs-tools | linux-initramfs-tool
Suggests: fdutils, linux-tools, linux-headers-4.13.0-21-generic
Supported: 5y
Download-Size: 20.8 MB
APT-Sources: http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
Description: Linux kernel image for version 4.13.0 on 64 bit x86 SMP
 This package contains the Linux kernel image for version 4.13.0 on
 64 bit x86 SMP.
 .
 Also includes the corresponding System.map file, the modules built by the
 packager, and scripts that try to ensure that the system is not left in an
 unbootable state after an update.
 .
 Supports Generic processors.
 .
 Geared toward desktop and server systems.
 .
 You likely do not want to install this package directly. Instead, install
 the linux-generic meta-package, which will ensure that upgrades work
 correctly, and that supporting packages are also installed.

[Sir Charles]

Edit to add - I think 14.13.0.21 was the fixed kernel - it's the 4.13.0.19 kernel prior that had the faulty driver enabled. Still in the repos though.

You are right, I misread it.

Code: Select all

Fix: The issue was fixed in kernel version 4.13.0-21 by configuring the kernel so it is not compiled with Intel SPI support. But previous affected machines still suffered from a broken BIOS.

Repair: If you still can boot into Ubuntu, you can recover your BIOS with the following steps:

1. Boot into Ubuntu
2. Download http://people.canonical.com/~ypwong/lp1734147/linux-image-4.15.0-041500rc6-generic_4.15.0-041500rc6.201712312330+20170103+1_amd64.deb
3. Install the downloaded package:
  $ sudo dpkg -i linux-image-4.15.0-041500rc6-generic_4.15.0-041500rc6.201712312330+20170103+1_amd64.deb
4. Make sure the kernel is installed without any error. Once installed, reboot.
5. At grub, choose the newly installed kernel. You can choose the "recovery" mode.
6. Reboot and go to BIOS settings to confirm your BIOS has been recovered.
7. In case your BIOS is not recovered, reboot to the new kernel, then reboot *once again* to the new kernel, do not enter BIOS settings before the reboot. After the second reboot, check BIOS.
8. If your BIOS issue remains, download another kernel from http://people.canonical.com/~ypwong/lp1734147/linux-image-4.15.0-041500rc6-generic_4.15.0-041500rc6.201712312330+clear+debug_amd64.deb, and use dpkg to install it, then repeat steps 4 to 6.

After your BIOS is fixed, the kernel packages you just installed are no longer needed, you can remove it by running 'sudo dpkg -r linux-image-4.15.0-041500rc6-generic'.

The patch used to build the linux v4.15 kernel in step 8 can be found at https://goo.gl/xUKJFR.

[Pjotr]

Main rule: old kernels always remain in the repo's, even though they always contain bugs (because if there were no bugs in them, there would be far less need for kernel updates to begin with).

This main rule has of course exceptions, but those are reserved for calamities.

This policy has probably to do with the wish to be as little disruptive as possible, and to give as much choice as possible to the users.

[michael louwe]

@ Marziano, .......

...

.
About Ubuntu 17.10's kernel 4.13 bricking some computers, the source of the problem was that the Ubuntu 17.10 ISO files which came with default kernel 4.13.16(.?) contained the Intel SPI driver bug. Affected computers that installed Ubuntu 17.10 from the buggy ISO files got bricked. The problem was partly solved when Canonical Inc replaced the buggy Ubuntu 17.10 ISO files with new ISO files containing the kernel 4.13.21 fix, ie by removing the Intel SPI driver.
... IOW, the root cause of the problem was the Ubuntu 17.10 ISO file, and not the buggy kernel 4.13.

It is highly doubtful that Canonical Inc would allow the Intel SPI driver bug to remain in the Ubuntu repositories, ie in Ubuntu kernel 4.13.0 to 4.13.19 or in other lower kernels, eg the 4.10 series. It is very likely that Canonical have already removed the buggy Intel SPI driver from those kernels and from the Ubuntu repositories. Otherwise, affected computers will continue to be bricked by ignorantly installing Ubuntu kernels 4.13.0 to 4.13.19.

[Sir Charles]

Thanks michael louwe and Pjotr for further clarifications. It's always good to get a broader perspective on things. I appreciate it.

[Pjotr]

It is highly doubtful that Canonical Inc would allow the Intel SPI driver bug to remain in the Ubuntu repositories, ie in Ubuntu kernel 4.13.0 to 4.13.19 or in other lower kernels, eg the 4.10 series. It is very likely that Canonical have already removed the buggy Intel SPI driver from those kernels and from the Ubuntu repositories. Otherwise, affected computers will continue to be bricked by ignorantly installing Ubuntu kernels 4.13.0 to 4.13.19.

Well, personally I wouldn't risk my hardware to try that out... I rather doubt that they've done that.

They should have, or at least they should have removed those kernels from the repo's (which would have required almost zero effort). But I doubt it.

[smurphos]

Given Meltdown/Spectre hit within days of them fixing that bug and removing old kernels is not standard practice they probably just haven't considered it yet.

Although it's not 100% clear that manually installing 4.13.0.19 or below will impact an affected model I wouldn't be trying it either.

[smurphos]

I am using Ubuntu update kernel utility to install kernel version 4.9. Does it mean that even though I have installed version 4.9.79, the security patches arent available downstream in Ubuntu but they are only available upstream?

Possibly so.

Its a bit confusing. One would expect the upstream and downstream versions of 4.79 or any kernel with same number to be the same.

They're not, and it's indeed confusing.... This is how to compare a downstream kernel number with an upstream kernel number:
https://sites.google.com/site/easylinux ... l-version-
(item 19, right column)

Handy (if long) table mapping Ubuntu kernels to the mainline kernel they are based on.

http://people.canonical.com/~kernel/inf ... n-map.html

[michael louwe]

...

...

...

.
According to these links, the Intel SPI driver bug was first introduced by kernel.org/Linus Torvald in their mainline/upstream kernel 4.11.2 in May 2017 and was only fixed by them in kernel 4.14 RCI on 12 November 2017, even though the patch had been available from July 2017 onwards. ...

https://bugzilla.kernel.org/show_bug.cgi?id=195951 (1 June 2017 - Booting kernel 4.11 triggers a reset of UEFI firmware settings on the next boot)
https://www.phoronix.com/forums/forum/p ... blem/page8 (Comment #74 - 23 Dec 2017 - ubuntu-17-10-temporarily-pulled-due-to-a-bios-corrupting-problem)
https://github.com/torvalds/linux/blob/ ... el-spi.txt (4 Jan 2017 - Upgrading BIOS using intel-spi)

From Oct 2017, the Ubuntu 17.10 ISO file shipped with Ubuntu kernel 4.13.16(= kernel.org/mainline kernel 4.13.4) = affected computers got hit by the Intel SPI driver bug when the users installed Ubuntu 17.10 or booted its Live media.
... A patched Ubuntu 17.10.1 ISO file with kernel 4.13.21 was released in Jan 2018. ( https://www.phoronix.com/scan.php?page= ... 1-Released - Ubuntu 17.10.1 ISOs Now Available To Avoid Thrashing Some UEFI Systems)

Seems, this very serious Intel SPI driver problem originated with kernel.org/Linus Torvald and the delay in patching the bug, ie their eagerness to introduce the feature for updating Intel BIOS firmware from Linux = wanted to copy Windows. AMD CPUs/motherboards were not affected.

In comparison, the Ubuntu 17.04 ISO file shipped with kernel 4.10.19, similar to LM 18.3 = not affected by the Intel SPI driver bug after install. But if their users install Ubuntu kernel 4.11.10 to 4.13.19(= mainline kernel 4.11.8 to 4.13.13) on affected Intel computers, will they be hit by this Intel SPI driver bug.? So far, no such news about bricked computers = those Ubuntu kernels have been patched(.?), ie the buggy Intel SPI driver has been removed.