Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Communications Network Networking Open Source Operating Systems Software Wireless Networking Linux Technology

Linux Kernel 3.18 Reaches End of Life (softpedia.com) 101

Posted by BeauHD from the last-in-line dept.
prisoninmate quotes a report from Softpedia: Linux kernel 3.18.48 LTS is here and it's the last in the series, which was marked for a January 2017 extinction since mid-April last year. According to the appended shortlog, the new patch changes a total of 50 files, with 159 insertions and 351 deletions. It brings an updated networking stack with Bluetooth, Bridge, IPv4, IPv6, CAIF, and Netfilter improvements, a couple of x86 fixes, and a bunch of updated USB, SCSI, ATA, media, GPU, ATM, HID, MTD, SPI, and networking (Ethernet and Wireless) drivers. Of course, this being the last maintenance update in the series, you are urged to move to a newer LTS branch, such as Linux kernel 4.9 or 4.4, which are far more secure and efficient than Linux 3.18 was. But Linux 3.18 appears to be used by Google and other vendors on a bunch of Android-powered devices, and even some Chromebooks use Linux kernel 3.18 on Chrome OS, so here's what the kernel developer suggests you do if you can't upgrade. "If you are _stuck_ on 3.18 (/me eyes his new phone), well, I might have a plan for you, that first involves you yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out. After you properly vent to them, drop me an email and let's see what we can come up with, you aren't in this sinking ship alone, and it's obvious your vendor isn't going to help out," said Greg Kroah-Hartman in the mailing list announcement.
This discussion has been archived. No new comments can be posted.

Linux Kernel 3.18 Reaches End of Life More

Linux Kernel 3.18 Reaches End of Life

Comments Filter:

  • Could this week get any worse? (Score:4, Funny)

    by 93 Escort Wagon ( 326346 ) on Wednesday February 08, 2017 @10:10PM (#53830313)

    First we lose Richard Hatch; now it's Linux kernel 3.18. Man...

  • Linux Kernel release process is broken (Score:3, Insightful)

    by KeithCu ( 925649 ) on Wednesday February 08, 2017 @10:19PM (#53830335)
    Last I checked the Linux kernel had 4672 bugs. Something is clearly wrong with the release process. Imagine if it took an airline 1-2 years to return your lost luggage [keithcu.com]?

    • Last I checked the Linux kernel had 4672 bugs. Something is clearly wrong with the release process.

      Last I checked, Microsoft wouldn't tell us how many bugs the Windows kernel has. The safest thing is to assume that the number is infinite. Something is wrong with Microsoft's release process.

      • Re: (Score:1)

        by KeithCu ( 925649 )
        Who knows how many kernel bugs are active in Windows on the ship date, but I doubt there are 4,600 of them. You might have to include the usermode code to get a number that large, and if they are working the way they used to: all the bugs would be looked at before a release, and the ones that aren't release critical (feature requests, performance, cleanups, etc.) would be postponed. It wouldn't have 1000s of crashing bugs. Check out the Linux bug list yourself and see if there is a problem. It is better to

  • I like articles that use real words (ones in the dictionary). Acronyms for technical terms is one thing, and brand names as well, but this is neither.

  • My phone is stuck on 3.4.42. Thanks Google (and Lenovo now I guess)

    I suppose it's still supported though, until April 2017

    • Re: (Score:2)

      by WarJolt ( 990309 )

      The problem is that Google doesn't mainline any of their changes. It rots in their "open source" repository and they reuse those code lines for new products long after it is wise to do so because some derivative hardware isn't supported by mainline.

        Googles open source philosophy is far from collaborative. They unilaterally change things without any thought about how it might affect other people. That is incompatible with the Linux kernel development.

  • Third Party Support (Score:1)

    by Anonymous Coward

    Linux is open source. Support doesn't have to come from kernel.org. Linaro are supporting 3.18 until December 2018 [linaro.org]. There may be other vendors committing to maintaining the kernel with at least security fixes for longer.
     

    • Distros. Red Hat supports 2.6.18 through 2020 (Score:4, Informative)

      by raymorris ( 2726007 ) on Wednesday February 08, 2017 @10:52PM (#53830469) Journal

      Most distros will support their long-term kernels well after kernell.org moves on. For example, Red Hat Enterprise, released in 2007, with kernel 2.6.18, has some support from Red hat until November 30, 2020.

      RHEL 6,RHEL 7, and their debranded CentOS twins provide important security updates for ten years. I use CentOS 6, kernel 2.6.32, supported from 2010 to 2020. I'll probably switch to CentOS 7 (or 8) in 2018 or so.

      • The second sentence is missing the version number. That should say:

        For example, Red Hat Enterprise 5, released in 2007 with kernel 2.6.18, has some support from Red Hat until November 30, 2020.

        For Red Hat 6 (kernel 2..32), they'll soon stop adding support for new hardware and it'll be security fixes and important bugs only. That may work for me until 8 is released. I prefer not to replace the OS more than once every ten years or so, so I'de prefer to skip version 7.

      • I just set up a new server running CentOS 7, kernel 3.10. Good to know it will be well supported into the future. I also pay for KernelCare, so I don't have to think about security patches.

        I still have a CentOS 6 server running 2.6.32 in a KVM virtual machine. It's thoroughly embedded with cPanel/WHM so upgrading it will be a pain in the butt.

        I use Funtoo Linux everywhere else, and have recently deployed 4.9 across the board on all of my (in production) Funtoo servers.

        • > so I don't have to think about security patches. ...
          > cPanel/WHM

          If you care *at all* about security and are running Cpanel or even worse Plesk, you probably want to make to turn off SuExec. Both php suexec and cgi suexec. Basically what suexec does is give all visitors to your site *permission* to change all of your files. In all likelihood one of your PHP scripts gives them the *mechanism* to do so.

          Suexec was designed for servers with a thousand hosting customers who have $20/year hosting accou

          • Thanks for the advice.

            The purpose of KernelCare is that they splice security patches into the kernel while it's running. That is what I was referring to in regards to not having to worry about security patches, and to further explain, I meant I don't have to worry about rebooting (and thus causing down time) after applying kernel security patches.

            I'm well aware of the problems with suExec and suPHP (and suHosin, etc).

            I used mod_ruid2 up until they finally incorporated support for ITK [sesse.net]. This specific server o

            • It seems my post was unclear. It *may* also be that you are so comfortable with your current knowledge that you are somewhat resistant to unfamiliar ideas. If that's so, that's fine. I've made a LOT of money over the last 20 years cleaning up rooted servers run by people who thought they understood this issue.

              > ITK. ... This allows each account to have permissions of 0600

              Whether you do suexec using mod_suexec, php_suexec, mod_ruid2, or mpm_ik doesn't really matter, either way the *effective* permiss

              • I'm not certain you understand how MPM ITK works.

                For each request, MPM-ITK will accept the incoming request, check the headers and determine which VirtualHost it belongs to. From there it will fork off a process and setuid/setgid's the process to the VirtualHost's defined uid/gid before handling the request. It's important to note that it uses setuid and setgid, NOT seteuid and setegid. Once that process is forked off, it's permissions are permanently set to the defined UID/GID.

                It's important to note that a

                • It's your server, you can of course do what you want. I'm just giving you information about how 90% of malware infections occur on web sites. For twenty years I've been remediating compromised servers, and this is how it normally happens.

                  > From there it will fork off a process and setuid/setgid's the process to the VirtualHost's defined uid/gid .. which has full permission to change any and all the files on the site.

                  > It's important to note that all SSH, and FTP daemons work in a very similar way.

                  Do

                  • Adding a password doesn't inheritly make it any more secure.

                    We're talking about protocols and internet facing applications.

                    The daemons accept connections as a root user, then forks off another process and setuid/setgid the process before handling the request. In the specific cases of FTP and SSH, the authentication still done by the root user. If there is an exploit at this level, authentication does absolutely nothing.

                    With MPM-ITK, all it does at the root user level is accept the connection, then hands the

                  • I think you seem to believe that having all user accounts readable by the apache process is a better security model.

                    Personally, I don't want all of the users able to snoop on each others files.

                    I would rather have a site be able to nuke its own files, but stay isolated to that uid/gid, than be able to read files in other accounts.

                    Proper offsite backups make this a non issue for my situation.

                    • > I would rather have a site be able to nuke its own files, but stay isolated to that uid/gid, than be able to read files in other accounts.

                      Sounds like you understand the trade-off. For me, I know that 99.99% of files in document_root are there for the express purpose of being made available to the public - that's why they are on the web site. Therefore I'm not TOO worried that people who have FTP/ssh access on the server can read those files. I'm *much* more concerned that visitors can add malware to t

                    • > That's great that you have proper offsite backup which you test on a regular basis, and retain several copies of backups from different times, so you can restore to a copy that was made *before* the malware was added, the site deleted, etc.

                      Indeed. I do. Like I said, I'm not new to this.

                      > Since you have that, you may be able to fairly easily have the backup process report which files changed, filtering out the files that are supposed to change regularly. That way you won't be serving up malware for m

                    • *continued, accidentally tapped the submit button*

                      These aren't the 'cheap' hosts either. Some accounts were costing upwards of $25USD per month for less than 1GB of storage. I'm not sure if any of them are still around.

  • ATM? (Score:2)

    by glitch! ( 57276 )

    They are still supporting ATM? I am really curious because I actually wrote ATM code. Fifteen years ago. Both device drivers and stack code. Great stuff, but that is ancient history. Can anyone tell what ATM has done in the last decade? Thanks!

  • Define "long term." (Score:5, Insightful)

    by msauve ( 701917 ) on Wednesday February 08, 2017 @11:25PM (#53830585)
    "yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out"

    3.18 was released slightly over 2 years ago (7 Dec 2014 [omgubuntu.co.uk]). It went LTS 3 months later (2015/3/11 [softpedia.com]). At the time, "it will be supported with patches for at least two more years from today." Now it's gone, less than 2 years later. And, 2 years isn't "long term" by any reasonable definition to begin with. Don't yell loudly at anyone who used it, yell loudly at Greg Kroah-Hartman and the other kernel maintainers for over-promising and under-delivering, who think 2 years is a long time and won't even keep that commitment. 3.16 (LTS) is projected to go to 2020 [kernel.org], when it's 5 1/2 years old (kudos to Ben Hutchings, who's a bit more realistic about what "long term" means).

    (and of course, anyone the size of Google should be able to put their own resource on maintaining a kernel they chose to use for longer if need be, not that they've figured out how to keep Android devices up-to-date anyway)

    • This, exactly. There's no reason to expect my phone or chromebook to need a new major kernel update within 2 years of purchase. Considering the development time in advance, I'd expect a tested kernel to be several months old before the device even launches.

      • This, exactly. There's no reason to expect my phone or chromebook to need a new major kernel update within 2 years of purchase.

        Of course there is - 'it's the economy, stupid!'. Nobody who makes portable consumer electronics wants you to have the same hardware two years after you bought it - they want a new one in your hands and fresh money out of your bank account by then. Never mind what that does to the environment and to non-renewable resources, and never mind what kind of world we're leaving to our heirs.

    • Re: (Score:3)

      by thsths ( 31372 )

      Yelling is usually a sign a bad social skills, as is recommending to yell. It is just not how normal people behave.

      And I agree he is just trying to detract from the fact that he promised something and did not deliver. 2 years is nothing - not enough even for the fast moving Ubuntu distribution, and certainly not enough for embedded development. Once the device is released, you usually do not want to change kernel versions, so 5 years would be more useful.

  • Linux xxx.yyy.com 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I'm operating at the bottom of the ocean and everything still works. :-)

    • Re: (Score:2)

      by fnj ( 64210 )

      Linux xxx.yyy.com 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I'm operating at the bottom of the ocean and everything still works. :-)

      Whoopdedoo. Linux 2.2 still works fine AT THE BOTTOM OF THE OCEAN. Not much of an attack surface exposure down there. There are plenty of Windows XP boxes in labs, with well-controlled access and no exposure to the internet, doing in-house work, un-patched for many years and without any anti-virus, that are still perfectly reli

  • Who cares about Android updating beyond 3.18 if they aren't even updating the patches within 3.18?
    Assume the OS you get when you buy your Android device is going to be the last update for it ever.

  • Who cares about EOL... (Score:3)

    by enriquevagu ( 1026480 ) on Thursday February 09, 2017 @07:44AM (#53831709)

    Who cares about EOL, when the firmware of your device includes a fixed kernel image which won't be updated, ever?

    I mean, my current Android phone (using Marshmallow) employs a kernel 3.4.42, released on April 2013 [kernel.org]. The current version of the 3.4 branch is 3.4.113 (source [kernel.org]), released on October 2016. I don't know if there are any critical (security, performance) improvements from 3.4.42 to 3.4.113, but I simply don't care becase I know the manufacturer won't publish an updated version of the firmware with a recent kernel. If a serious kernel security bug appears and it is solved in a new kernel version, it won't be solved in my device. The situation is way better when you consider Linux desktop distributions, but still...

    What I mean is that for at least 99% of the people, the kernel is an atomic part of the firmware of their device (phone) and they won't bother about updating it. With this in mind, there should be no recommendations to the final users ("yelling very loudly" because your Android phone employs a given kernel version, haha), EOL is only significant for upgradeable systems. Not even phone designers need to worry about using LTS: they know they will never update their kernel.

    • So? The recipe doesn't change: yell very loud at your phone's manufacturer that they have to cut the crap and start delivering updates. Outdated kernels are a security liability.

Slashdot Top Deals

8 Catfish = 1 Octo-puss

Close