Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Ubuntu

Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers (bleepingcomputer.com) 233

An anonymous reader writes: Ubuntu Xenial 16.04 users who updated to receive the Meltdown and Spectre patches are reporting they are unable to boot their systems and have been forced to roll back to an earlier Linux kernel image. The issues were reported by a large number of users on the Ubuntu forums and Ubuntu's Launchpad bug tracker. Only Ubuntu users running the Xenial 16.04 series appear to be affected.

All users who reported issues said they were unable to boot after upgrading to Ubuntu 16.04 with kernel image 4.4.0-108. Canonical, the company behind Ubuntu OS, deployed Linux kernel image 4.4.0-108 as part of a security update for Ubuntu Xenial 16.04 users, yesterday, on January 9. According to Ubuntu Security Notice USN-3522-1 and an Ubuntu Wiki page, this was the update that delivered the Meltdown and Spectre patches.

This discussion has been archived. No new comments can be posted.

Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers

Comments Filter:
  • by Lab Rat Jason ( 2495638 ) on Wednesday January 10, 2018 @12:23PM (#55901703)

    It seems that these companies (Microsoft and Ubuntu and others) are forgetting everything about sound software development practices here. They're in such a hurry to deploy patches that they aren't taking the time to fully test them. The cure is worse than the ailment.

    • by king neckbeard ( 1801738 ) on Wednesday January 10, 2018 @12:32PM (#55901795)
      To be fair, there is a major security flaw covering the majority of desktop CPUs sold over the last two decades. You are correct that they have not done proper testing, but this is on a ridiculous scale.
      • Comment removed (Score:4, Insightful)

        by account_deleted ( 4530225 ) on Wednesday January 10, 2018 @01:57PM (#55902699)
        Comment removed based on user account deletion
        • by chill ( 34294 ) on Wednesday January 10, 2018 @02:44PM (#55903173) Journal

          Meltdown is Intel-only and requires the ability to run binaries on the victim's computer. If you can run binaries on the victim's computer, you probably already have enough access to do whatever it is you want to do that made you want to hack them in the first place. The extent to which Meltdown adds security issues is miniscule.

          That isn't really accurate. Meltdown is potentially devastating for virtual machines and set-ups like shared hosting. Getting a VM slice on a much larger machine is where Meltdown scares cloud-deployed companies. Spin up a small VM, execute Meltdown exploit, and compromise who else is on that host. Ditto with a shared web host.

        • by Eravnrekaree ( 467752 ) on Wednesday January 10, 2018 @04:04PM (#55903751)

          Meltdown is easier to exploit, The hacks will get better as well. So it is a very serious problem, information leaks can be very harmful, think passwords and encryption keys. These can then allow for write attacks. Don't underestimate the capabilities of people to find ways to exploit this. It may seem far fetched but time and time again far fetched things have a way of being turned into quite practical exploits.

        • by sjames ( 1099 )

          If you're running on a VM in the cloud, it's not that hard for someone else to run an executable (in their own VM) on the same server. Meltdown can cross VMs.

          That's why the big rush to a workaround patch.

      • by SeaFox ( 739806 )

        To be fair, there is a major security flaw covering the majority of desktop CPUs sold over the last two decades.

        It's been around for two decades, and known about for years based on earlier reports, and the world did not some to an end during that time. Taking a few months for proper testing before deploying isn't going to be an issue.

        People don't install Ubuntu to be on the bleeding edge.

      • Comment removed based on user account deletion
    • It seems that these companies (Microsoft and Ubuntu and others) are forgetting everything about sound software development practices here. They're in such a hurry to deploy patches that they aren't taking the time to fully test them. The cure is worse than the ailment.

      Both Microsoft and Ubuntu are plagued by the vast permutations of hardware out there, all the combinations of motherboard, cpu, video, etc. Aren't there identified problems with various anti-virus software? Did some driver developer out there try something tricky too that is incompatible with the fix(es)? Historically various problems with Windows came from 3rd party drivers not necessarily Microsoft itself, perhaps Ubuntu is having similar problems?

    • by Alumoi ( 1321661 )

      Why bother with testing when there are a lot of paying beta testers around? Windows 10 anyone?

    • To be fair it must be a nightmare to fix something like this so the fix works on a wide variety of configurations and doesn't kill performance on any of them. Especially if news of the exploit gets leaked or discovered independently.

      https://en.wikipedia.org/wiki/... [wikipedia.org]

      On March 27, 2017 researchers at Austria's Graz University of Technology developed a proof-of-concept that could grab RSA keys from Intel SGX enclaves running on the same system within five minutes by using certain CPU instructions in lieu of a fine-grained timer to exploit cache DRAM side-channels.

      In June 2017, KASLR was found to have a large class of new vulnerabilities. Research at Graz University showed how to solve these vulnerabilities by preventing all access to unauthorized pages. A presentation on the resulting KAISER technique was submitted for the Black Hat congress in July 2017, but was rejected by the organizers. Nevertheless, this work led to kernel page-table isolation (KPTI, originally known as KAISER) in 2017, which was confirmed to eliminate a large class of security bugs, including the not-yet-discovered Meltdown - a fact confirmed by the Meltdown authors.

      In July 2017, research made public on the CyberWTF website by security researcher Anders Fogh outlined the use of a cache timing attack to read kernel space data by observing the results of speculative operations conditioned on data fetched with invalid privileges.

      Meltdown was discovered independently by Jann Horn from Google's Project Zero, Werner Haas and Thomas Prescher from Cyberus Technology, as well as Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from Graz University of Technology. The same research teams that discovered Meltdown also discovered a related CPU security vulnerability now called Spectre.

      On October 2017, Kernel ASLR support on amd64 was added in NetBSD-current, making NetBSD the first BSD system to support kernel address space layout randomization (KASLR).

      On November 14, 2017, security researcher Alex Ionescu publicly mentioned changes in the new version of Windows 10 that would cause some speed degradation without explaining the necessity for the changes, just referring to similar changes in Linux.

      After affected hardware and software vendors had been made aware of the issue on July 28, 2017, the two vulnerabilities were made public jointly, on January 3, 2018, several days ahead of the coordinated release date of January 9, 2018 as news sites started reporting about commits to the Linux kernel and mails to its mailing list. As a result, patches were not available for some platforms, such as Ubuntu, when the vulnerabilities were disclosed.

    • by cyn1c77 ( 928549 )

      It seems that these companies (Microsoft and Ubuntu and others) are forgetting everything about sound software development practices here. They're in such a hurry to deploy patches that they aren't taking the time to fully test them. The cure is worse than the ailment.

      Is it really that they are forgetting or do they just not care?

    • The reality is their are hundreds of thousands if not millions of hardware and software combinations, no company or OSS provider can come even close to testing it all for such a significant system change. All they can do is make a best effort.
      • All they can do is make a best effort.

        No: it would appear the standard alternative to a best effort is to make a fairly pathetic, half-assed effort.

    • Ubuntu case is different. 16.04 is LTS and is supposed to be supported until 2021. In reality, when something is fixed in the latest version (17.10) that could be fixed in 16.04 as well, that's not always the case. And today these patches prove that even security fixes are botched on an older 16.04 version.
  • ...haven't had any issues.
    • Running something on a hypervisor is not the same as running it on bare metal.
    • uname -a
      ******* 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

      My CPU is: Intel Core i3-2120 CPU @ 3.30Ghz

      Updated my Linux Mint 18.3 Cinnamon 64 bit this afternoon and all is well after reboot.
      Ran sysbench tests on CPU and File IO before and after and noticed no difference.

  • by Anonymous Coward on Wednesday January 10, 2018 @12:27PM (#55901733)

    "have been forced to roll back to an earlier Linux kernel image."

    So, not actually bricked then...

    WORDS MEAN THINGS!

    • by AvitarX ( 172628 ) <me@@@brandywinehundred...org> on Wednesday January 10, 2018 @12:50PM (#55902017) Journal

      Doesn't this just mean pressing down in grub once, then setting it to use that kernel by default?

      This is barely even a slight annoyance.

    • by El_Muerte_TDS ( 592157 ) on Wednesday January 10, 2018 @12:51PM (#55902025) Homepage

      It's 2018, we have SmartBricks now. You can change the software of your SmartBricks.

    • by Billy O'Connor ( 3638647 ) on Wednesday January 10, 2018 @12:55PM (#55902063)
      Yeah, but who's going to click on a link that says "Ubuntu kernels rolled back to the one from the day before yesterday"? Do you know ANYTHING about social media marketing strategies? It's like you're not even trying.
    • by ThanatosMinor ( 1046978 ) on Wednesday January 10, 2018 @01:04PM (#55902133)

      Article title updated because we used the term "bricking" incorrectly. Bleeping Computer regrets the error.

      We apologise for the fault in the title. Those responsible have been sacked.

    • by celeb8 ( 682138 )
      YES THANK YOU came here to post this
    • Exactly. If the kernel scrambled the UEFI files or hosed the firmware beyond recovery, that is a bricking. Having to boot from an earlier kernel in GRUB2... well, that is just an "oh shit", like anything else on the OS side. Definitely not good, but it doesn't mean that you have to buy a new motherboard.

      I think part of the confusion come in with a lot of appliances blurring the line between BIOS and OS, combined with the lack of control of the OS. A kernel panic on a phone preventing it from starting co

      • However, on desktop/server PCs, we still have the option (for now...) to go back to a previous kernel.

        Shhh! Lennart might be lurking.

  • by OrangeTide ( 124937 ) on Wednesday January 10, 2018 @12:28PM (#55901757) Homepage Journal

    Let those hackers try and get into my system now!

    • A picky one: spectre & meltdown do not help entering your system (not directly at least), the attacker has to be connected to run the programs.
  • Already fixed... (Score:5, Informative)

    by Anonymous Coward on Wednesday January 10, 2018 @12:37PM (#55901849)

    Kernel 4.4.0-109, which fixes this problem, has already been pushed out.
    Apparently, the PTI fix was not quite backported correctly.
    For details, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741934

    • I have the exact same symptom using the -109 update, i.e., attempting to boot that kernel ends up doing a system reboot. Said reboot happens after I've successfully entered my full disk encryption password.
      • by jrumney ( 197329 )
        I don't think that is the same symptom. I updated three servers yesterday - one Skylake, one Broadwell, one Sandy Bridge. The first two went OK, the Sandy Bridge one just locked up part way through the boot - even Ctrl-Alt-Del was non functional, and required a power cycle to reboot and select the old -104 kernel.
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Wednesday January 10, 2018 @12:42PM (#55901893)

    Bricking is the equivalent of applying a killpoke. A software action that makes the hardware henceforth unusable.

    This just screws up the kernel and requires you to set up a fresh one, perhaps reinstalling the core system. On Linux this is usually nothing more than a minor annoyance.

    Again: it's not bricking. Bricking is when a software update or piece of code renders my smartphone not more useful than a brick and irreversibly so.

    Stop using the word just because it's new and describes something significant. It doesn't make your news more interesting, it makes your news false.

    Thank you.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      It's part of a larger Millennial Trend to make their stupid, worthless "contributions" seem much more impressive.

      "literally" -> absolutely, positively NOT literally
      "hacking" -> doing something differently, like putting avocado on toast
      "crypto" -> some retarded cartoon-backed pseudo currency

  • Upgraded my kernel yesterday without issue. Got a notice this morning 4.4.0-109.132 was available.
  • Not bricked #2305473 (Score:5, Informative)

    by Fly Swatter ( 30498 ) on Wednesday January 10, 2018 @12:43PM (#55901909) Homepage
    Press down arrow at boot menu screen.
    • Not all environments allow access to boot menue screens. In particular, virtualized hosts do not allow access unless the owner of the virtual server elects to allow graphical access to the hypervisor. This is technologically feasible but proscribed for basic security reasons by various virtualization providers, such as AWS and many locally administered virtualiztion toolkits.

  • by yorgasor ( 109984 ) <ron@@@tritechs...net> on Wednesday January 10, 2018 @12:44PM (#55901925) Homepage

    I don't think it means what you think it means. If working around the bug means selecting a different item from the menu to boot, it's not really bricked.

  • by Antique Geekmeister ( 740220 ) on Wednesday January 10, 2018 @12:44PM (#55901933)

    Failing to use a particular new kernel is not "bricking". Bricking, as commonly used, means the physical hardware is unrecoverable and needs to be replaced. Recovering a failed Ubuntu kernel means being able to select a different kernel to boot with. This means console access or access to the disk image. These are problematic and can disable production servers. But it's much less destructive than ruining the physical hardware.

    • What I understood the word "brick" to originally mean, was that a device had been rendered so completely unusable that it had no more value or functionality than a brick, as there was no means for anyone other than the manufacturer to restore the device to any form of operation. Usually this was in spite of the fact that the hardware itself was fully functional.

      As most of these devices were locked down regarding firmware and encryption, to limit rooting the device, etc., most of the causes were software r
  • Wow! Guess I'm fortunate to have a newer kernel. I was running the 4.10 kernel and the update upgraded me to the 4.13 kernel. All my computers (including one running the equivalent level of Linux Mint) booted just fine with the 4.13.0-26 kernel.

  • by michaelcole ( 704646 ) on Wednesday January 10, 2018 @12:50PM (#55902013)
    From the article comments moments ago:

    > Technically, if you are able to boot with an older kernel, your computer is not bricked. ;-)

    > You are right. I've updated the title.
  • by mykepredko ( 40154 ) on Wednesday January 10, 2018 @12:56PM (#55902077) Homepage

    Just saw the headline and panicked, checking my Linux systems (all running ubuntu 16.04 LTS) and did a quick check:

    myke@mimeticsL01:~$ uname -a
    Linux mimeticsL01 4.4.0-108-generic #131-Ubuntu SMP Sun Jan 7 14:34:49 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    myke@mimeticsL01:~$

    I've never had a problem with Ubuntu updates (although I RFTA, it sounds like all Ubuntu users have an issue at one time or another). I suspect that the kernel update was tested before it was released so this updates affects some subset of the systems out there.

    Like many other people, I was very concerned when i saw the headline saying the updated was "bricking" systems - whoever wrote the headline needs to have the term "bricking" explained to them (ideally with an actual brick).

    In the future, msmash, you might want to be a bit less sensational in the headlines and make sure you understand if the terms used in it are correct.

  • by TheDarkener ( 198348 ) on Wednesday January 10, 2018 @12:57PM (#55902089) Homepage

    This is not what "bricking" is. If you can fix it (i.e. roll back to an earlier kernel image in this case), it's simply a botched kernel update.

    C'mon, msmash.

  • All new crashes:

    [ 22.462856] kernel BUG at /build/linux-J4_1pC/linux-4.4.0/mm/slub.c:3627!
    [ 22.462874] invalid opcode: 0000 [#1] SMP

    Yay for regressions.

  • I'd previously upgraded to 4.10.x (for some hardware support). Xenial still wanted me to do the 4.4.0-108 kernel. Needless to say, I didn't do it.

  • A bricked machine is completely useless. If you can roll back to an earlier kernel, you are not bricked. Read the article and don't just parrot a clickbait headline.

  • IMO, there's a difference between bricking a Linux box vs a Windows box. Unless you have a System 76, you probably installed Linux yourself, or had your nephew do it. That means you have the install media and can reinstall the damn thing.

    OTOH, Windows machines don't come with install disks. If Windows is foobar, then for all intensive porpoises, it's bricked (short of taking it to a PC repair place that will unbrick it for what you can pay for a new one).

  • by w1zz4 ( 2943911 ) on Wednesday January 10, 2018 @02:34PM (#55903081)
    Kernel 4.4.0-109.132 has been issued to fix this
  • ...and a slow ISP(Frontier). I was actually in the process of downloading the update when I stumbled across this article and canceled the update. It is the xxxx.109.x kernel update but I've seen at least 1 report of that still having an issue here. I'll just wait a couple of days for this to get sorted out....

  • I ran into a similar issue on an old AMD machine in another distro. Changed a kernel option to noapic and it worked.
  • Comment removed based on user account deletion
  • Absolutely no disturbances with Ubuntu 16.04.3 with kernel 4.4.0-109-generic.

  • The headline: "Meltdown and Spectre Patches Bricking Ubuntu"

    The reality: The new kernel you upgraded to won't boot. So at the grub menu, scroll down to your old kernel and boot that. Good thing this kind of issue was anticipated and is easy to deal with as a result.

  • Bricking is when you cannot interact with the device, making it the equivalent of a brick. Please stop saying when a OS install is messed up it is bricked.

"I got everybody to pay up front...then I blew up their planet." "Now why didn't I think of that?" -- Post Bros. Comics

Working...