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

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

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 > > >

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

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

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

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

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*

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

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.

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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. > >

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

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

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

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

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

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

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

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*

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

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

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

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

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