Announcement

Collapse
No announcement yet.

Ubuntu 18.04's Heavily Patched Kernel Opens Door To Lockdown Bypass, Breaks Secure Boot

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ubuntu 18.04's Heavily Patched Kernel Opens Door To Lockdown Bypass, Breaks Secure Boot

    Phoronix: Ubuntu 18.04's Heavily Patched Kernel Opens Door To Lockdown Bypass, Breaks Secure Boot

    With Ubuntu 18.04 when running on its Linux 4.15 kernel and not one of the newer hardware enablement kernels, in the mess of patches back-ported to the release it ends up being vulnerable to bypassing the kernel lockdown security and compromising UEFI Secure Boot that is persistent across reboots...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why do they even use kernel 4.15? The previous version (4.14) would have been an upstream LTS release.

    Comment


    • #3
      So this delay happens because they are retarded?

      Comment


      • #4
        I sincerely hope he disclosed the flaw to Canonical before release, because it wasn't clear on the article.

        And of heavily patched kernels, what is the problem? Isn't that the whole modus operandi of Redhat? Nobody seems to care that they do that for a living.

        Comment


        • #5
          I honestly worry about this issue with damn near every LTS distribution. Something like this happening is exactly why I complained about the upcoming OpenSUSE 15.2 release that is using an EOL'd 5.3.18 kernel.

          Comment


          • #6
            Originally posted by archkde View Post
            Why do they even use kernel 4.15? The previous version (4.14) would have been an upstream LTS release.
            LTS distributions are ran by committees and committees end up compromising into a retarded decision. See my previous post. We'll be having a similar discussion in 18 more days.

            Comment


            • #7
              Originally posted by skeevy420 View Post
              I honestly worry about this issue with damn near every LTS distribution. Something like this happening is exactly why I complained about the upcoming OpenSUSE 15.2 release that is using an EOL'd 5.3.18 kernel.
              LTS does not mean jackshit. I bet there's a lot more SUSE people on the 5.3.x branch than people doing the kernel.org 3.6.x series.

              Comment


              • #8
                Originally posted by skeevy420 View Post
                I honestly worry about this issue with damn near every LTS distribution. Something like this happening is exactly why I complained about the upcoming OpenSUSE 15.2 release that is using an EOL'd 5.3.18 kernel.
                Indeed, a decision I found somewhat bizarre as 5.4 LTS was released only two months later in the November 2019 and plenty of time to get things in sync for July 2020.

                Comment


                • #9
                  Buuuuuut....it's stable ! Obsolete, but stable.

                  Comment


                  • #10
                    Originally posted by skeevy420 View Post
                    I honestly worry about this issue with damn near every LTS distribution. Something like this happening is exactly why I complained about the upcoming OpenSUSE 15.2 release that is using an EOL'd 5.3.18 kernel.
                    There is nothing to worry about, openSUSE uses the kernel that they deem appropriate to use and have engineers who know how a kernel works. Among other things, Leap uses the same kernel of SUSE that is intended for the corporate world, therefore in practice much safer than others.
                    In this case it seems to be a Canonical error, it can happen, as it can also happen with the vanilla kernel.

                    Comment

                    Working...
                    X