Re: Year 2038 time set problem
BTW - the problem with rebooting is not kernel problem. Its thinks like my workstation having 40 documents open on it, going back over year I hate to kill my desktop...among other things On Mon, Mar 05, 2018 at 07:26:23AM +0100, Greg KH wrote: > On Mon, Mar 05, 2018 at 01:15:03AM -0500, Ruben Safir wrote: > > On 03/05/2018 01:00 AM, Greg KH wrote: > > > "How many security issues were those systems > > > vulnerable to over that period of time? All of them." > > > > > > So I'm understanding. And yet, the kernel is getting harder and harder > > to manage. It takes hours to just walk through all the choices. > > You're doing it wrong. Don't ever walk through "all the choices". > > Take a distro kernel, boot your box, plug in all of the devices you want > to support, then do: > 'make localmodconfig' > in your own kernel drectory and spend 5 minutes building your new > kernel and then booting into it. > > > I went from using opensuse to using a rolling release of Artix, which is > > arch based. One of the things I've noticed is that the number of kernel > > upgrades are brisk, which with opensuse, it was rare for a kernel > > upgrade. I thought most of these upgrades was updated hardware options > > and features, and not security. Opensuse would get upset if you didn't > > use their derivative of the kernel. > > Then use your distros version of a kernel. opensuse is great, as is > arch, and a few other community-based distros, like Fedora. I trust > them to get it right with kernel updates. If you don't want to do it > yourself, use one of those "big 3" and feel quite comfortable with > rebooting every few weeks and all will be fine. > > thanks, > > greg k-h > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Mar 05, 2018 at 07:26:23AM +0100, Greg KH wrote: > On Mon, Mar 05, 2018 at 01:15:03AM -0500, Ruben Safir wrote: > > On 03/05/2018 01:00 AM, Greg KH wrote: > > > "How many security issues were those systems > > > vulnerable to over that period of time? All of them." > > > > > > So I'm understanding. And yet, the kernel is getting harder and harder > > to manage. It takes hours to just walk through all the choices. > > You're doing it wrong. Don't ever walk through "all the choices". > > Take a distro kernel, boot your box, plug in all of the devices you want > to support, then do: > 'make localmodconfig' I did a make oldconfig on a virtual system yesterday and it had pages of choics it considered new. That was on my laptop, a few years old. :( > in your own kernel drectory and spend 5 minutes building your new > kernel and then booting into it. > > > I went from using opensuse to using a rolling release of Artix, which is > > arch based. One of the things I've noticed is that the number of kernel > > upgrades are brisk, which with opensuse, it was rare for a kernel > > upgrade. I thought most of these upgrades was updated hardware options > > and features, and not security. Opensuse would get upset if you didn't > > use their derivative of the kernel. > > Then use your distros version of a kernel. opensuse is great, as is > arch, and a few other community-based distros, like Fedora. I trust > them to get it right with kernel updates. If you don't want to do it > yourself, use one of those "big 3" and feel quite comfortable with > rebooting every few weeks and all will be fine. > > thanks, > > greg k-h > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Mar 05, 2018 at 03:35:24PM +, Alex Arvelaez wrote: > On Mar 5, 2018 6:30 AM, Bernd Petrovitsch wrote: > > > > On Mon, 2018-03-05 at 02:35 +, Alex Arvelaez wrote: > > [...] > > > Device makers don't love updating their devices, I don't see how you > > > could fix that sadly. What's your solution? > > > > It's much worse for varying reasons. > > > > And why should "we" (whoever that is) fix the problems of others? > > I wasn't saying the kernel community should take on this problem. I > was saying the kernel community can't possibly fix this problem. We can't fix it "completely", but we can do a lot to help make it easier. And we have, over 12 years ago we made the "Cambridge Promise" at a kernel summit where we said "We make the guarantee that updating to anew kernel will not break your system or userspace". Yes we sometimes mess up, but we try our best to always fix it. We came up with the idea of the "stable" kernels, containing bugfixes to make it easier for companies to use and rely on for their devices. The list of rules for the stable kernel are easy to understand and everyone can see all patches being applied so they know if they need to update their devices or not. Then, when we realized that people want to stick to a specific kernel version for a longer period of time than just 3 months, we came out with the idea of "Long Term Supported" kernels to help those companies out. Then, when 2 years was too short (SoC companies are horrid in getting their code upstream), I promised to try to maintain a kernel release for 6 years for them. Now if they don't use that kernel in their devices (I have a whole raft of them here to watch if they update or not) that experiment will not be repeated, but for now we are trying to help companies out here. If this latest attempt doesn't work well, then we will continue to try to come up with solutions for this problem, while actively working with the device makers as we rely on them as well, this isn't a one-way street, it's an ecosystem. Those makers are the community just as much as any other Linux user. And at the same time as all of the above, we are adding hardening features to make any bugs that are later found, not be a real issue. That's been the case for many of the recently found bugs lately. If only the device makers would have actually turned those options on. So go enable those options, to ignore them is almost as foolish as not updating the kernel. Sorry for the rant, we are trying to make this dirt simple and easy for people to update, and be protected with the releases they do run. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 4, 2018 at 10:14 PM, Ruben Safir wrote: > On 03/04/2018 09:35 PM, Alex Arvelaez wrote: >> If you don't need high availability, what's the problem with the occasional >> reboot? > > I have a life, and its a chore to reboot the 3 boxes after every > upgrade. It runs my phones, my TV, my house security, and my mail and > webserver and booting them all is a PIA. If it is raining security > holes with every kernel upgrade, that is a big problem, and that is > before all these appliances. > > Advice? Who am I to give advice? On the face of it, I would say they > need to harden the kernel base release. But I am not qualified to give > anyone advice. If a kernel can't be reasonably secure in a 2 year > period, as a consumer I can only be unhappy about it and a bit dismayed. > But no one owes me anything. Now might be a good time to bring up some of Robert Morris Sr' advice: turn it off and unplug it . Otherwise, you have to live with the risk and inconveniences. Jeff ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mar 5, 2018 6:30 AM, Bernd Petrovitsch wrote: > > On Mon, 2018-03-05 at 02:35 +, Alex Arvelaez wrote: > [...] > > Device makers don't love updating their devices, I don't see how you > > could fix that sadly. What's your solution? > > It's much worse for varying reasons. > > And why should "we" (whoever that is) fix the problems of others? I wasn't saying the kernel community should take on this problem. I was saying the kernel community can't possibly fix this problem. > The upstream can't do anything directly if the downstream simply > refuses to update (if there are fixes to real threats) and/or reboot > (if it's the kernel). We agree on all points. :) Regards, Alex ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 07:34 AM, Ruben Safir wrote: On 03/05/2018 03:50 AM, valdis.kletni...@vt.edu wrote: If it's the former, then you have to learn that reboots are like changing the oil in your car yeah, BTW, my car doesn't need its oil changed any longer. It hasn't needed to be done before 100,000 miles since the mid-1980s. I only WISH that the kernel development used automobile industry standards for reliability and security. I'll bite. Is this a mazda rotary? They quit using those some time ago, right? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Mar 05, 2018 at 07:20:35AM -0500, Ruben Safir wrote: > On 03/05/2018 06:29 AM, Bernd Petrovitsch wrote: > > And why should "we" (whoever that is) fix the problems of others? > > > > The upstream can't do anything directly if the downstream simply > > refuses to update (if there are fixes to real threats) and/or reboot > > (if it's the kernel). > > > So any system where you need to, or want to install it and forget about > it for a long period of time, the Linux kernel can not be considered a > choice for that usage because it needs contact oversite and upgrades. No kernel can be considered for such a choice, this is not unique to Linux or any other operating system, sorry. good luck! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, 05 Mar 2018 07:20:35 -0500, Ruben Safir said: > So any system where you need to, or want to install it and forget about > it for a long period of time, the Linux kernel can not be considered a > choice for that usage because it needs contact oversite and upgrades. That's true for *any* software. Guess you get to build it out of cogs and levers. vxworks has bugs too: https://www.cvedetails.com/product/15063/Windriver-Vxworks.html?vendor_id=95 And I'm willing to bet a large pizza with everything but anchovies that the Vxworks total would be higher if it had enough market share to make it worth researching. Oh, and somebody found a 30 year old bug in VMS recently. pgpSRTdHkFQqR.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 03:50 AM, valdis.kletni...@vt.edu wrote: > If it's the > former, then you have to learn that reboots are like changing the oil > in your car yeah, BTW, my car doesn't need its oil changed any longer. It hasn't needed to be done before 100,000 miles since the mid-1980s. I only WISH that the kernel development used automobile industry standards for reliability and security. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 03:50 AM, valdis.kletni...@vt.edu wrote: > Give an example of a system - *ANY* system - where you *can't* afford > the time down for a reboot, but the downtime for a hardware failure *is* > acceptable. this is a black hole of a conversation. I see no benefit to it at this point. Your not even reading what I wrote. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 06:29 AM, Bernd Petrovitsch wrote: > And why should "we" (whoever that is) fix the problems of others? > > The upstream can't do anything directly if the downstream simply > refuses to update (if there are fixes to real threats) and/or reboot > (if it's the kernel). So any system where you need to, or want to install it and forget about it for a long period of time, the Linux kernel can not be considered a choice for that usage because it needs contact oversite and upgrades. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 03:50 AM, valdis.kletni...@vt.edu wrote: > Give an example of a system - *ANY* system - where you *can't* afford > the time down for a reboot, but the downtime for a hardware failure *is* > acceptable. You are right. No you move on to another target.. where you can show you are right -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, 2018-03-05 at 02:35 +, Alex Arvelaez wrote: [...] > Device makers don't love updating their devices, I don't see how you > could fix that sadly. What's your solution? It's much worse for varying reasons. And why should "we" (whoever that is) fix the problems of others? The upstream can't do anything directly if the downstream simply refuses to update (if there are fixes to real threats) and/or reboot (if it's the kernel). MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, 04 Mar 2018 23:50:32 -0500, Ruben Safir said: > Don't pretend to understand what I can and can not afford. Your not > picking security policy for Google. What your failing to address, > because you are so blinded to your own frame of reference, is that your > solution leaves out well over 90% of the devices connected to the > internet, some of those devices connected to things like nuclear power > plants. Others are just VOIP appliances. Give an example of a system - *ANY* system - where you *can't* afford the time down for a reboot, but the downtime for a hardware failure *is* acceptable. If you connect something to a nuclear power plant and can't afford a reboot time, what is your plan if the device fails entirely? If you can't stand your VOIP box being down at 3AM when there's no calls in progress, what do you intend to use for voice service if you're down because a DIMM failed? Don't confuse "the downtime for a reboot pisses me off personally" with "if we take downtime at all, it's A Serious Problem". If it's the former, then you have to learn that reboots are like changing the oil in your car - refusing to do periodic maintenance will bite you eventually. If it's the latter, and you *aren't* already doing things like HA to deal with hardware failures, *you are being negligent*. And yes, we're talking in "court of law" mode here for some things - if you knew that downtime would cause damages (either physical or monetary) and you didn't do anything about it, you better have a *really* hefty insurance policy covering negligence on your part. And if you *are* doing stuff to deal with hardware failures, *then a reboot is a non-issue*. (And by the way - as I've mentioned, managing reboots is the *easy* part of updating an Internet of Pwned Things device. The hard part is getting the vendor to produce an update in the first place...) pgp00YRXtzGUa.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Mar 05, 2018 at 01:15:03AM -0500, Ruben Safir wrote: > On 03/05/2018 01:00 AM, Greg KH wrote: > > "How many security issues were those systems > > vulnerable to over that period of time? All of them." > > > So I'm understanding. And yet, the kernel is getting harder and harder > to manage. It takes hours to just walk through all the choices. You're doing it wrong. Don't ever walk through "all the choices". Take a distro kernel, boot your box, plug in all of the devices you want to support, then do: 'make localmodconfig' in your own kernel drectory and spend 5 minutes building your new kernel and then booting into it. > I went from using opensuse to using a rolling release of Artix, which is > arch based. One of the things I've noticed is that the number of kernel > upgrades are brisk, which with opensuse, it was rare for a kernel > upgrade. I thought most of these upgrades was updated hardware options > and features, and not security. Opensuse would get upset if you didn't > use their derivative of the kernel. Then use your distros version of a kernel. opensuse is great, as is arch, and a few other community-based distros, like Fedora. I trust them to get it right with kernel updates. If you don't want to do it yourself, use one of those "big 3" and feel quite comfortable with rebooting every few weeks and all will be fine. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 01:00 AM, Greg KH wrote: > "How many security issues were those systems > vulnerable to over that period of time? All of them." So I'm understanding. And yet, the kernel is getting harder and harder to manage. It takes hours to just walk through all the choices. I went from using opensuse to using a rolling release of Artix, which is arch based. One of the things I've noticed is that the number of kernel upgrades are brisk, which with opensuse, it was rare for a kernel upgrade. I thought most of these upgrades was updated hardware options and features, and not security. Opensuse would get upset if you didn't use their derivative of the kernel. With Artix, it really seems that kernels get upgraded weekly -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/05/2018 12:53 AM, Greg KH wrote: >> no, it won't work. It requires supervision > Then you are doing it wrong :) That goes without saying. I'm always doing things wrong :) I'm very creative at doing things wrong. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 04, 2018 at 10:14:58PM -0500, Ruben Safir wrote: > Advice? Who am I to give advice? On the face of it, I would say they > need to harden the kernel base release. But I am not qualified to give > anyone advice. If a kernel can't be reasonably secure in a 2 year > period, as a consumer I can only be unhappy about it and a bit dismayed. Be dismayed, the state of computer security is not there yet, sorry, and it's doubtful that it ever will be (although it keeps getting better...) But seriously, if you have a system that is exposed to the world, you have to change it all the time as the world changes. You don't live in a bubble of a stable ecosystem, no one does. Ok, yes, there are some systems that do. Take for example two of my most favorite examples of the use of Linux: - ballast stabilizer for super-mega-yachts - automatic cow milking machines The first one does not interact with the world in a manner that it needs to be updated regularly, if ever, as communication from it to the kernel comes in through a known "good" channel (i.e. the on-board ship network which had better be firewalled from the world...) Same for the second one. Both of them interact with the physical world very directly (some might say more directly than your laptop or phone), but both do not interact with the digital world much, if at all. And that's the key here. Just keep your systems updated, it's really simple. If you can't do that, then prepare to have those systems be full of known security issues very very quickly. As someone said at a conference recently when they asked the audience about the longest uptime for any of the attendees systems (which turned out to be about 5 years.), "How many security issues were those systems vulnerable to over that period of time? All of them." good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 04, 2018 at 05:25:41PM -0500, valdis.kletni...@vt.edu wrote: > On Sun, 04 Mar 2018 21:54:03 +0100, Greg KH said: > > > To be fair, the next 4.1.y release to come out in a few days should have > > almost all of these issues resolved. So as long as you are keeping your > > systems up to date, all should be fine. > > So the next one will be the "So long, and thanks for all the fish" release of > 4.1? :) Based on the size of it, that just might be the case :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 04, 2018 at 11:16:40PM -0500, Ruben Safir wrote: > On 03/04/2018 11:07 PM, Alex Arvelaez wrote: > > easy: set up a cronjob to do it for you. > > no, it won't work. It requires supervision Then you are doing it wrong :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 11:15 PM, valdis.kletni...@vt.edu wrote: > The big problem *there* isn't that a reboot is often required. Yes, it is a problem. If you have 25 thousand signal switches that depend on, and build a wifi network for signally and telemetry, you aren't going to be able to put all those devices behind a cluster, and you sure as hell aren't going to reboot them all every week. These things need to be all but bulletproof on installation. That is the way that the world works outside of a server farm closet. ... just as an example -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 11:15 PM, valdis.kletni...@vt.edu wrote: >> I only had a system fry once >> while it was up an running since the late 1990's until today, and in >> that case it was wild power surge and the hardware was up and running in >> 20 minutes with a swap out of the hard drive. > The fact that you've kept a system going for 8 years without a reboot > isn't proof that actually doing so is a good idea security wise. > I made that point with regard to the silly notion that somehow the hardware would just magically fry periodically. On the scale I'm working at, hardware failure over decades is rare. Whether it is reasonable to expect to be able to use a kernel securely for 8 years is a problem I leave for the experts. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 11:15 PM, valdis.kletni...@vt.edu wrote: > I repeat what I said - if you can't afford a reboot because it's mission > critical, > you can't afford to *not* be doing HA or load balancing or something. I know, that is the thing about talking to guys like you. It is a personality type. Its worst that talking to a rock. You just repeat the same insane advice over and over. Complete tunnel vision. You don't even have a clue as to how to deal with this problem. Truthfully, you don't know what the problem even is. Don't pretend to understand what I can and can not afford. Your not picking security policy for Google. What your failing to address, because you are so blinded to your own frame of reference, is that your solution leaves out well over 90% of the devices connected to the internet, some of those devices connected to things like nuclear power plants. Others are just VOIP appliances. This conversation is now over, at least for me. Repeating the same bad advice is not contributing to anyone, and especially not I. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 11:07 PM, Alex Arvelaez wrote: > easy: set up a cronjob to do it for you. no, it won't work. It requires supervision -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, 04 Mar 2018 21:21:13 -0500, Ruben Safir said: > I am not setting up a high availability cluster in my house, thank you. > And fwiw, I've run systems for 6-8 years without rebooting on pc > hardware. My little fanless fit/pc service running an intel atom had at > one time run 5 years without rebooting. I only had a system fry once > while it was up an running since the late 1990's until today, and in > that case it was wild power surge and the hardware was up and running in > 20 minutes with a swap out of the hard drive. The fact that you've kept a system going for 8 years without a reboot isn't proof that actually doing so is a good idea security wise. > The linux kernel is integrated into dozens of devices which never see > the light of day for kernel upgrades from PPOE routers, IOT devices, > cellphones, VOIP boxes, electrocardiograms, menu displays for McDonalds, > signal boxes on train systems, etc etc etc. The big problem *there* isn't that a reboot is often required. The problem is that the vendors won't ship a patched system to reboot *into*. > What has been described is a huge security problem and your solution is > a non-starter and doesn't help the broader problem. I repeat what I said - if you can't afford a reboot because it's mission critical, you can't afford to *not* be doing HA or load balancing or something. The Internet of Pwned Things problem is with systems where a reboot *is* feasible (are you going to notice if your light bulb reboots at 3AM when it's off anyhow?), but vendors have no ecomonic incentive to provide fixes after they've got your money (unless they can monetize you post-purchase - and most people won't pay for a support contract, so the vendor's only realistic choice is monetizing your data..) And that's a totally orthogonal issue. pgpZVmKSMakNp.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mar 4, 2018 10:15 PM, Ruben Safir wrote: > > On 03/04/2018 09:35 PM, Alex Arvelaez wrote: > > If you don't need high availability, what's the problem with the occasional > > reboot? > > I have a life, and its a chore to reboot the 3 boxes after every easy: set up a cronjob to do it for you. > upgrade. It runs my phones, my TV, my house security, and my mail and > webserver and booting them all is a PIA. If it is raining security > holes with every kernel upgrade, that is a big problem, and that is > before all these appliances. there is no "raining security holes with every kernel update", simply bugs get found after release or can't make it to that release cycle(a bug fix may cause regressions that need to be fixed, testing, etc.). Keep your OS up-to-date and you'll be fine. Regards, Alex ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 09:35 PM, Alex Arvelaez wrote: > If you don't need high availability, what's the problem with the occasional > reboot? I have a life, and its a chore to reboot the 3 boxes after every upgrade. It runs my phones, my TV, my house security, and my mail and webserver and booting them all is a PIA. If it is raining security holes with every kernel upgrade, that is a big problem, and that is before all these appliances. Advice? Who am I to give advice? On the face of it, I would say they need to harden the kernel base release. But I am not qualified to give anyone advice. If a kernel can't be reasonably secure in a 2 year period, as a consumer I can only be unhappy about it and a bit dismayed. But no one owes me anything. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mar 4, 2018 9:21 PM, Ruben Safir wrote: > > On 03/04/2018 05:24 PM, valdis.kletni...@vt.edu wrote: > > If you can't afford the disruption of service a reboot causes, you *really* > > need to be deploying HA or load-balancer solutions. > > > > Because if you can't afford a reboot's worth of 15-20 minutes of downtime, > > you > > *really* can't afford the 6-8 hours you're probably going to be down if a > > chip > > soldered onto the motherboard/backplane fries. > > > > (All of $DAYJOB's important systems are behind HA or load-balancers, as > > well as > > HA-capable storage. Let's just say that some vendors make it easier than > > others to set up 8+2 RAID6 across 10 separate shelves of storage, and > > designing > > mutli-petabyte solutions without single points of failure is harder than it > > looks :) > > > > > These questions always lead into these philosophical discussions as to > how I should run my boxes and theoretical flights of opinionated rubbish > that I am not interested in. I got the answer to the question I needed > and it is very sobering. > > I am not setting up a high availability cluster in my house, thank you. If you don't need high availability, what's the problem with the occasional reboot? > The linux kernel is integrated into dozens of devices which never see > the light of day for kernel upgrades from PPOE routers, IOT devices, > cellphones, VOIP boxes, electrocardiograms, menu displays for McDonalds, > signal boxes on train systems, etc etc etc. > > What has been described is a huge security problem and your solution is > a non-starter and doesn't help the broader discussion Device makers don't love updating their devices, I don't see how you could fix that sadly. What's your solution? Regards, Alex ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 05:24 PM, valdis.kletni...@vt.edu wrote: > If you can't afford the disruption of service a reboot causes, you *really* > need to be deploying HA or load-balancer solutions. > > Because if you can't afford a reboot's worth of 15-20 minutes of downtime, you > *really* can't afford the 6-8 hours you're probably going to be down if a chip > soldered onto the motherboard/backplane fries. > > (All of $DAYJOB's important systems are behind HA or load-balancers, as well > as > HA-capable storage. Let's just say that some vendors make it easier than > others to set up 8+2 RAID6 across 10 separate shelves of storage, and > designing > mutli-petabyte solutions without single points of failure is harder than it > looks :) > These questions always lead into these philosophical discussions as to how I should run my boxes and theoretical flights of opinionated rubbish that I am not interested in. I got the answer to the question I needed and it is very sobering. I am not setting up a high availability cluster in my house, thank you. And fwiw, I've run systems for 6-8 years without rebooting on pc hardware. My little fanless fit/pc service running an intel atom had at one time run 5 years without rebooting. I only had a system fry once while it was up an running since the late 1990's until today, and in that case it was wild power surge and the hardware was up and running in 20 minutes with a swap out of the hard drive. The linux kernel is integrated into dozens of devices which never see the light of day for kernel upgrades from PPOE routers, IOT devices, cellphones, VOIP boxes, electrocardiograms, menu displays for McDonalds, signal boxes on train systems, etc etc etc. What has been described is a huge security problem and your solution is a non-starter and doesn't help the broader problem. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, 04 Mar 2018 21:54:03 +0100, Greg KH said: > To be fair, the next 4.1.y release to come out in a few days should have > almost all of these issues resolved. So as long as you are keeping your > systems up to date, all should be fine. So the next one will be the "So long, and thanks for all the fish" release of 4.1? :) pgpRfITyojKOU.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, 04 Mar 2018 20:47:15 +, Alex Arvelaez said: > You can kexec into the newer kernel to avoid rebooting if you absolutely must > but yeah the best practice is to keep your system up to date and that requires > some disruption of service. If you can't afford the disruption of service a reboot causes, you *really* need to be deploying HA or load-balancer solutions. Because if you can't afford a reboot's worth of 15-20 minutes of downtime, you *really* can't afford the 6-8 hours you're probably going to be down if a chip soldered onto the motherboard/backplane fries. (All of $DAYJOB's important systems are behind HA or load-balancers, as well as HA-capable storage. Let's just say that some vendors make it easier than others to set up 8+2 RAID6 across 10 separate shelves of storage, and designing mutli-petabyte solutions without single points of failure is harder than it looks :) pgpjYnjpCA11v.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 04, 2018 at 03:20:48PM -0500, Ruben Safir wrote: > On 03/04/2018 01:31 PM, valdis.kletni...@vt.edu wrote: > > Note that saying "The CPU isn't vulnerable to Meltdown/Spectre, therefor > > the 4.1 kernel is OK" is *incredibly* wrong. > > > > For the record, since 4.1 came out, there's been at *least* a dozen security > > issues in the Linux kernel that have been a *lot* scarier for security > > professionals than the Meltdown/Spectre issue. That only got any news > > coverage > > because it was an actual hardware design flaw that was believed to be > > difficult > > to easily fix with software changes... > > By this standard, it is necessary to update the kernel and reboot nearly > every week. Is that right? That is correct. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, Mar 04, 2018 at 01:31:04PM -0500, valdis.kletni...@vt.edu wrote: > On Sun, 04 Mar 2018 06:59:46 +, tali.pe...@nuvoton.com said: > > It is not secure because it is not fixed for these issues: > > https://meltdownattack.com/ > > Note that saying "The CPU isn't vulnerable to Meltdown/Spectre, therefor > the 4.1 kernel is OK" is *incredibly* wrong. > > For the record, since 4.1 came out, there's been at *least* a dozen security > issues in the Linux kernel that have been a *lot* scarier for security > professionals than the Meltdown/Spectre issue. That only got any news > coverage > because it was an actual hardware design flaw that was believed to be > difficult > to easily fix with software changes... To be fair, the next 4.1.y release to come out in a few days should have almost all of these issues resolved. So as long as you are keeping your systems up to date, all should be fine. But again, this kernel is going to be end-of-life in a few short weeks, so you had better be moving off of it already, or else you will be in trouble soon. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mar 4, 2018 3:21 PM, Ruben Safir wrote: > > On 03/04/2018 01:31 PM, valdis.kletni...@vt.edu wrote: > > Note that saying "The CPU isn't vulnerable to Meltdown/Spectre, therefor > > the 4.1 kernel is OK" is *incredibly* wrong. > > > > For the record, since 4.1 came out, there's been at *least* a dozen security > > issues in the Linux kernel that have been a *lot* scarier for security > > professionals than the Meltdown/Spectre issue. That only got any news > > coverage > > because it was an actual hardware design flaw that was believed to be > > difficult > > to easily fix with software changes... > > By this standard, it is necessary to update the kernel and reboot nearly > every week. Is that right? You can kexec into the newer kernel to avoid rebooting if you absolutely must but yeah the best practice is to keep your system up to date and that requires some disruption of service. There's also kernel live patching which would allow you to patch the kernel without rebooting but I don't know how well supported that option is. > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Regards, Alex ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On 03/04/2018 01:31 PM, valdis.kletni...@vt.edu wrote: > Note that saying "The CPU isn't vulnerable to Meltdown/Spectre, therefor > the 4.1 kernel is OK" is *incredibly* wrong. > > For the record, since 4.1 came out, there's been at *least* a dozen security > issues in the Linux kernel that have been a *lot* scarier for security > professionals than the Meltdown/Spectre issue. That only got any news > coverage > because it was an actual hardware design flaw that was believed to be > difficult > to easily fix with software changes... By this standard, it is necessary to update the kernel and reboot nearly every week. Is that right? -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sun, 04 Mar 2018 06:59:46 +, tali.pe...@nuvoton.com said: > It is not secure because it is not fixed for these issues: > https://meltdownattack.com/ Note that saying "The CPU isn't vulnerable to Meltdown/Spectre, therefor the 4.1 kernel is OK" is *incredibly* wrong. For the record, since 4.1 came out, there's been at *least* a dozen security issues in the Linux kernel that have been a *lot* scarier for security professionals than the Meltdown/Spectre issue. That only got any news coverage because it was an actual hardware design flaw that was believed to be difficult to easily fix with software changes... For example, here's a partial list of known security issues fixed in *just* 4.14.8: (You want the full list, it's here: https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html Looks like there were some 298 CVE numbers assigned to the Linux kernel after the 4.1 release date. Note that this doe *NOT* include fixed bugs that had security implications but were not assigned a CVE number) CVE-2017-17857 The check_stack_boundary function in kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging mishandling of invalid variable stack read operations. CVE-2017-17856 kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging the lack of stack-pointer alignment enforcement. CVE-2017-17855 kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging improper use of pointers in place of scalars. CVE-2017-17854 kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (integer overflow and memory corruption) or possibly have unspecified other impact by leveraging unrestricted integer values for pointer arithmetic. CVE-2017-17853 kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging incorrect BPF_RSH signed bounds calculations. CVE-2017-17852 kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging mishandling of 32-bit ALU ops. CVE-2017-17806 The HMAC implementation (crypto/hmac.c) in the Linux kernel before 4.14.8 does not validate that the underlying cryptographic hash algorithm is unkeyed, allowing a local attacker able to use the AF_ALG-based hash interface (CONFIG_CRYPTO_USER_API_HASH) and the SHA-3 hash algorithm (CONFIG_CRYPTO_SHA3) to cause a kernel stack buffer overflow by executing a crafted sequence of system calls that encounter a missing SHA-3 initialization. CVE-2017-17805 The Salsa20 encryption algorithm in the Linux kernel before 4.14.8 does not correctly handle zero-length inputs, allowing a local attacker able to use the AF_ALG-based skcipher interface (CONFIG_CRYPTO_USER_API_SKCIPHER) to cause a denial of service (uninitialized-memory free and kernel crash) or have unspecified other impact by executing a crafted sequence of system calls that use the blkcipher_walk API. Both the generic implementation (crypto/salsa20_generic.c) and x86 implementation (arch/x86/crypto/salsa20_glue.c) of Salsa20 were vulnerable. pgpQzN33s9K52.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
It is not secure because it is not fixed for these issues: https://meltdownattack.com/ If you're CPU is not listed there (unlikely) or your use case does not need that much security( depending on your application) you can stay with 4.1. Fixing these vulnerabilities is a lot of work and no one will fix them for old OS. Tali Perry -Original Message- From: kernelnewbies-requ...@kernelnewbies.org [mailto:kernelnewbies-requ...@kernelnewbies.org] Sent: Thursday, March 1, 2018 7:00 PM To: kernelnewbies@kernelnewbies.org Subject: Kernelnewbies Digest, Vol 88, Issue 1 Send Kernelnewbies mailing list submissions to kernelnewbies@kernelnewbies.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.kernelnewbies.org_mailman_listinfo_kernelnewbies&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=5-jOvjYshFdcjobN4MAbTtpuvsF8AX3cHai1kFhWbCo&m=5WHSMfKEgDeA1L5AJ0SixtlVmggN8l66pLQJV_mbEPo&s=yn9lHYs-jhadLZh1tVPLrBb9Zk1cllKS9CbE_J3_ITQ&e= or, via email, send a message with subject or body 'help' to kernelnewbies-requ...@kernelnewbies.org You can reach the person managing the list at kernelnewbies-ow...@kernelnewbies.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Kernelnewbies digest..." Today's Topics: 1. Re: Year 2038 time set problem (techi eth) 2. Re: Year 2038 time set problem (Greg KH) -- Message: 1 Date: Thu, 1 Mar 2018 14:49:05 +0530 From: techi eth To: Greg KH Cc: Valdis Kletnieks , kernelnewbies@kernelnewbies.org Subject: Re: Year 2038 time set problem Message-ID: Content-Type: text/plain; charset="utf-8" I am just trying to know why 4.1 kernel is insecure ? I have try to look but not able to get right answer. Could you please give me hint or link. I only see it is going to EOL by May 2018. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_category_releases.html&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=5-jOvjYshFdcjobN4MAbTtpuvsF8AX3cHai1kFhWbCo&m=5WHSMfKEgDeA1L5AJ0SixtlVmggN8l66pLQJV_mbEPo&s=apTb5GBuyMFf5VtDS12PkFJxZdN_PGgur3KES7GW5LI&e= Thanks On Sat, Feb 24, 2018 at 9:20 PM, Greg KH wrote: > On Sat, Feb 24, 2018 at 07:29:35PM +0530, techi eth wrote: > > I am trying on 32 Bit micro board with ubifs file system with Linux > Kernel > > 4.1. > > And in your testing, did you find any problems? > > Also note that the 4.1 kernel is very old and obsolete and insecure, > and should NOT be used for any devices in the year 2038. > > best of luck! > > greg k-h > -- next part -- An HTML attachment was scrubbed... URL: <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.kernelnewbies.org_pipermail_kernelnewbies_attachments_20180301_13cb2216_attachment-2D0001.html&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=5-jOvjYshFdcjobN4MAbTtpuvsF8AX3cHai1kFhWbCo&m=5WHSMfKEgDeA1L5AJ0SixtlVmggN8l66pLQJV_mbEPo&s=1Gfz5A_quFFmclyBIGvBEHg-YdY2U0ZB5yErBWtd7C4&e= > ---------- Message: 2 Date: Thu, 1 Mar 2018 13:04:14 +0100 From: Greg KH To: techi eth Cc: Valdis Kletnieks , kernelnewbies@kernelnewbies.org Subject: Re: Year 2038 time set problem Message-ID: <20180301120414.gb31...@kroah.com> Content-Type: text/plain; charset=us-ascii On Thu, Mar 01, 2018 at 02:49:05PM +0530, techi eth wrote: > I am just trying to know why 4.1 kernel is insecure ? I have try to > look but not able to get right answer. > > Could you please give me hint or link. I only see it is going to EOL > by May 2018. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_ca > tegory_releases.html&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k > -EoDM&r=5-jOvjYshFdcjobN4MAbTtpuvsF8AX3cHai1kFhWbCo&m=5WHSMfKEgDeA1L5A > J0SixtlVmggN8l66pLQJV_mbEPo&s=apTb5GBuyMFf5VtDS12PkFJxZdN_PGgur3KES7GW > 5LI&e= Yes, why would you use a kernel that is going to be end-of-life in a few months, in the year 2038? What is going to keep it "secure" until then? thanks, greg k-h -- Subject: Digest Footer ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.kernelnewbies.org_mailman_listinfo_kernelnewbies&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=5-jOvjYshFdcjobN4MAbTtpuvsF8AX3cHai1kFhWbCo&m=5WHSMfKEgDeA1L5AJ0SixtlVmggN8l66pLQJV_mbEPo&s=yn9lHYs-jhadLZh1tVPLrBb9Zk1cllKS9CbE_J3_ITQ&e= -- End of Kernelnewbies Digest, Vol 88, Issue 1 ===
Re: Year 2038 time set problem
On Thu, Mar 01, 2018 at 02:49:05PM +0530, techi eth wrote: > I am just trying to know why 4.1 kernel is insecure ? I have try to look > but not able to get right answer. > > Could you please give me hint or link. I only see it is going to EOL by May > 2018. > > https://www.kernel.org/category/releases.html Yes, why would you use a kernel that is going to be end-of-life in a few months, in the year 2038? What is going to keep it "secure" until then? thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
I am just trying to know why 4.1 kernel is insecure ? I have try to look but not able to get right answer. Could you please give me hint or link. I only see it is going to EOL by May 2018. https://www.kernel.org/category/releases.html Thanks On Sat, Feb 24, 2018 at 9:20 PM, Greg KH wrote: > On Sat, Feb 24, 2018 at 07:29:35PM +0530, techi eth wrote: > > I am trying on 32 Bit micro board with ubifs file system with Linux > Kernel > > 4.1. > > And in your testing, did you find any problems? > > Also note that the 4.1 kernel is very old and obsolete and insecure, and > should NOT be used for any devices in the year 2038. > > best of luck! > > greg k-h > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
Hi, 2018-02-26 16:21 GMT+01:00 : > On Mon, 26 Feb 2018 14:15:53 +0100, Piotr Figiel said: > >> According to kernel.org website 4.1 has projected EOL in May 2018. Is >> the information about kernel releases on kernel.org irrelevant/ >> shouldn't be trusted? Or my understanding of longterm kernel trees is >> incorrect? > > Do you *really* want to be doing any new development on something that goes > off > support in 3 months? > > Why are you even looking at 4.1? I guess because original post author asked about 4.1. I'm more concerned about general rule, not this specific kernel branch. > (Heck, even my Raspberry Pi and my Linksys router are running 4.14 based > kernels :) That's nice. Best regards, Piotr. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
Hi, 2018-02-24 16:50 GMT+01:00 Greg KH : > Also note that the 4.1 kernel is very old and obsolete and insecure, and > should NOT be used for any devices in the year 2038. According to kernel.org website 4.1 has projected EOL in May 2018. Is the information about kernel releases on kernel.org irrelevant/ shouldn't be trusted? Or my understanding of longterm kernel trees is incorrect? Which trees do get security updates? Best regards, Piotr. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Security updates of Linux kernel (was: Re: Year 2038 time set problem)
Hi, 2018-02-26 15:16 GMT+01:00 Greg KH : > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: >> 2018-02-24 16:50 GMT+01:00 Greg KH : >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and >> > should NOT be used for any devices in the year 2038. >> According to kernel.org website 4.1 has projected EOL in May 2018. > Yes, 3 months from now. >> Is the information about kernel releases on kernel.org irrelevant/ >> shouldn't be trusted? Or my understanding of longterm kernel trees is >> incorrect? > No, it is correct, but note that since 4.1.y is about to be end-of-life, > it is receiving very few updates. No new device should be considering > to use it for their kernel version because it will not be supported very > soon now. Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is already insecure (while it's stated on kernel.org that it's currently supported). I just wonder where is the boundary as to one can expect the kernel to still get the security updates. Is there a consensus about a reliable source of information which kernels get fixes for certain security issues? Or is sticking with the most recent /stable/ kernel the only recommended approach? Commit messages often didn't mention any CVE or didn't indicate clearly a security problem so it's pretty hard to track it (semi-manually or automatically or without going in depth into commit details). Thanks, Best regards, Piotr. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Feb 26, 2018 at 01:19:41PM -0800, Dave Stevens wrote: > it makes me curious Greg. The little board *might* easily and lots of > other little boards *definitely will* be put into IoT gadgets for which > no updates are realistically available but whose owners will want to > use them as long as possible. It seems this means an abundance of small > and perhaps not so small devices will fail when the time comes. Maybe, and if those devices can not be updated in the field, they have worse problems to deal with than a the 2038 problem :) > I don't suppose I'm the only person curious about the ramifications, > could you refer me to relevant work? Ramifications of what, shipping a device that can not be updated? Or the 2038 problem? For the 2038 problem, search the archives of lwn.net, it has been covered there for many years as people have been working on various solutions for different parts of the kernel. For "shipping a device that can not be updated", well, that's a simple way to create a botnet of broken devices that are instantly insecure... hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, 26 Feb 2018 15:16:32 +0100 Greg KH wrote: > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: > > Hi, > > > > 2018-02-24 16:50 GMT+01:00 Greg KH : > > > Also note that the 4.1 kernel is very old and obsolete and > > > insecure, and should NOT be used for any devices in the year > > > 2038. > > > > According to kernel.org website 4.1 has projected EOL in May 2018. > > Yes, 3 months from now. > > > Is the information about kernel releases on kernel.org irrelevant/ > > shouldn't be trusted? Or my understanding of longterm kernel trees > > is incorrect? > > No, it is correct, but note that since 4.1.y is about to be > end-of-life, it is receiving very few updates. No new device should > be considering to use it for their kernel version because it will not > be supported very soon now. > > In fact, if you are using 4.1.y, you have already been told to move > off of it as soon as possible for this very reason. > > > Which trees do get security updates? > > The kernels listed on that page, but be aware that as the end-of-life > time approaches, the releases and updates get very infrequent. You > should always just update to a newer kernel version, or, if you are > stuck at a specific kernel version due to some hardware or SoC > requirements, get your support from that company as you are already > paying for it. > > Hope this helps, > > greg k-h it makes me curious Greg. The little board *might* easily and lots of other little boards *definitely will* be put into IoT gadgets for which no updates are realistically available but whose owners will want to use them as long as possible. It seems this means an abundance of small and perhaps not so small devices will fail when the time comes. I don't suppose I'm the only person curious about the ramifications, could you refer me to relevant work? TIA Dave > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Security updates of Linux kernel (was: Re: Year 2038 time set problem)
On Mon, Feb 26, 2018 at 04:24:34PM +0100, Piotr Figiel wrote: > Hi, > > 2018-02-26 15:16 GMT+01:00 Greg KH : > > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: > >> 2018-02-24 16:50 GMT+01:00 Greg KH : > >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and > >> > should NOT be used for any devices in the year 2038. > >> According to kernel.org website 4.1 has projected EOL in May 2018. > > Yes, 3 months from now. > >> Is the information about kernel releases on kernel.org irrelevant/ > >> shouldn't be trusted? Or my understanding of longterm kernel trees is > >> incorrect? > > No, it is correct, but note that since 4.1.y is about to be end-of-life, > > it is receiving very few updates. No new device should be considering > > to use it for their kernel version because it will not be supported very > > soon now. > > Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is > already insecure (while it's stated on kernel.org that it's currently > supported). I just wonder where is the boundary as to one can expect > the kernel to still get the security updates. It all depends. Right now, 4.1.y is vulnerable to the Spectre issue. As is 4.4.y. Will those kernels ever get those fixes, who knows, do you want to do the backport work, or just update to a newer kernel? And depending on your architecture, 4.4.y and 4.9.y is vunerable to Meltdown as well. And those kernels will not get fixed for known reasons I've documented elsewhere. There are other issues that are fixed in newer kernels that are not backported further back due to various issues, so you should always use a newer kernel release to be sure. > Is there a consensus about a reliable source of information which > kernels get fixes for certain security issues? Or is sticking with the > most recent /stable/ kernel the only recommended approach? This. > Commit messages often didn't mention any CVE or didn't indicate > clearly a security problem so it's pretty hard to track it > (semi-manually or automatically or without going in depth into commit > details). CVEs mean nothing, you can't rely on them. They are only good for if a bug is reported to the CVE numbering people, that's it. And even then, can you properly track a CVE issue that takes 100s of patches to resolve (like Meltdown and Spectre do?) I sure can not... For a full description on this whole thing, please see this post where I describe how the kernel developers treat "security" bugs, and how to ensure you are running a secure system: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, 26 Feb 2018 14:15:53 +0100, Piotr Figiel said: > According to kernel.org website 4.1 has projected EOL in May 2018. Is > the information about kernel releases on kernel.org irrelevant/ > shouldn't be trusted? Or my understanding of longterm kernel trees is > incorrect? Do you *really* want to be doing any new development on something that goes off support in 3 months? Why are you even looking at 4.1? That was all the way back in June 2015, and since then, there have been 220,344 commits totalling: [/usr/src/linux] git diff --shortstat v4.1 v4.16-rc3 55263 files changed, 8740289 insertions(+), 2695706 deletions(-) (Heck, even my Raspberry Pi and my Linksys router are running 4.14 based kernels :) And feel free to 'name and shame' if a vendor is doing something that traps you at that release - that's a vendor behavior that should be discouraged. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: > Hi, > > 2018-02-24 16:50 GMT+01:00 Greg KH : > > Also note that the 4.1 kernel is very old and obsolete and insecure, and > > should NOT be used for any devices in the year 2038. > > According to kernel.org website 4.1 has projected EOL in May 2018. Yes, 3 months from now. > Is the information about kernel releases on kernel.org irrelevant/ > shouldn't be trusted? Or my understanding of longterm kernel trees is > incorrect? No, it is correct, but note that since 4.1.y is about to be end-of-life, it is receiving very few updates. No new device should be considering to use it for their kernel version because it will not be supported very soon now. In fact, if you are using 4.1.y, you have already been told to move off of it as soon as possible for this very reason. > Which trees do get security updates? The kernels listed on that page, but be aware that as the end-of-life time approaches, the releases and updates get very infrequent. You should always just update to a newer kernel version, or, if you are stuck at a specific kernel version due to some hardware or SoC requirements, get your support from that company as you are already paying for it. Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sat, 24 Feb 2018 19:29:35 +0530, techi eth said: > I am trying on 32 Bit micro board with ubifs file system with Linux Kernel > 4.1. Is this board something that has a realistic expectation of still being in use in 2038? What's making you worry about 2038 issues? I'm willing to bet that the mostly likely cause of problems inside the kernel will be ubifs. But there's an even bigger chances that something in your userspace isn't 2038 clean yet. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Sat, Feb 24, 2018 at 07:29:35PM +0530, techi eth wrote: > I am trying on 32 Bit micro board with ubifs file system with Linux Kernel > 4.1. And in your testing, did you find any problems? Also note that the 4.1 kernel is very old and obsolete and insecure, and should NOT be used for any devices in the year 2038. best of luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
I am trying on 32 Bit micro board with ubifs file system with Linux Kernel 4.1. On Fri, Feb 23, 2018 at 6:48 PM, wrote: > On Fri, 23 Feb 2018 15:13:30 +0530, techi eth said: > > > Which Linux kernel version have Year 2038 problem solved for Linux > running > > on 32 Bit system. > > > > https://en.wikipedia.org/wiki/Year_2038_problem > > Did you read references 15 through 17 on that page? > > Also, the answer isn't a strict "Linux v5.91 fixes it" - the problem > wasn't fixed in > one commit. So for instance, some filesystems had 64 bit timestamps from > the very beginning, while there's probably at least one or two that still > need work. > > And if your problem is that you've got some ancient ext2 file system > images that > you have to keep around for forensic reasons, no kernel version is going > to help > (And yes, that could happen - as part of my job, I've had to keep disk > images around > for close to a decade due to ongoing legal action, and I've got users who > need to > keep research data for 30 years due to grant restrictions). > > So the *real* question here is - what data/hardware/whatever are you > looking at > where the 2038 problem is possibly relevant? > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Year 2038 time set problem
On Fri, 23 Feb 2018 15:13:30 +0530, techi eth said: > Which Linux kernel version have Year 2038 problem solved for Linux running > on 32 Bit system. > > https://en.wikipedia.org/wiki/Year_2038_problem Did you read references 15 through 17 on that page? Also, the answer isn't a strict "Linux v5.91 fixes it" - the problem wasn't fixed in one commit. So for instance, some filesystems had 64 bit timestamps from the very beginning, while there's probably at least one or two that still need work. And if your problem is that you've got some ancient ext2 file system images that you have to keep around for forensic reasons, no kernel version is going to help (And yes, that could happen - as part of my job, I've had to keep disk images around for close to a decade due to ongoing legal action, and I've got users who need to keep research data for 30 years due to grant restrictions). So the *real* question here is - what data/hardware/whatever are you looking at where the 2038 problem is possibly relevant? pgp_o7iFQZnBm.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies