Year 2038 time set problem

Year 2038 time set problem

[techi eth]

Hi,



Which Linux kernel version have Year 2038 problem solved for Linux running
on 32 Bit system.

https://en.wikipedia.org/wiki/Year_2038_problem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180223/1f779070/attachment.html>

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180223/4f89a980/attachment-0001.sig>

Year 2038 time set problem

[techi eth]

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, <valdis.kletnieks@vt.edu> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180224/f5ac7e25/attachment.html>

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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.

Year 2038 time set problem

[Piotr Figiel]

Hi,

2018-02-24 16:50 GMT+01:00 Greg KH <greg@kroah.com>:
> 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.

Year 2038 time set problem

[Greg KH]

On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote:
> Hi,
> 
> 2018-02-24 16:50 GMT+01:00 Greg KH <greg@kroah.com>:
> > 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

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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.

Year 2038 time set problem

[Piotr Figiel]

Hi,

2018-02-26 16:21 GMT+01:00  <valdis.kletnieks@vt.edu>:
> 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.

Year 2038 time set problem

[Dave Stevens]

On Mon, 26 Feb 2018 15:16:32 +0100
Greg KH <greg@kroah.com> 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 <greg@kroah.com>:  
> > > 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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[techi eth]

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 <greg@kroah.com> 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: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180301/13cb2216/attachment.html>

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Greg KH]

On Mon, Mar 05, 2018 at 03:35:24PM +0000, Alex Arvelaez wrote:
> On Mar 5, 2018 6:30 AM, Bernd Petrovitsch <bernd@petrovitsch.priv.at> wrote:
> >
> > On Mon, 2018-03-05 at 02:35 +0000, 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

Year 2038 time set problem

[Jeffrey Walton]

On Sun, Mar 4, 2018 at 10:14 PM, Ruben Safir <ruben@mrbrklyn.com> 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

Year 2038 time set problem

[Alex Arvelaez]

On Mar 5, 2018 6:30 AM, Bernd Petrovitsch <bernd@petrovitsch.priv.at> wrote:
>
> On Mon, 2018-03-05 at 02:35 +0000, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180305/2b035fac/attachment-0001.html>

Year 2038 time set problem

[Darin Avery]

On 03/05/2018 07:34 AM, Ruben Safir wrote:
> On 03/05/2018 03:50 AM, valdis.kletnieks at 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?

Year 2038 time set problem

[Greg KH]

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!

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180305/49b919f4/attachment.sig>

Year 2038 time set problem

[Ruben Safir]

On 03/05/2018 03:50 AM, valdis.kletnieks at 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

Year 2038 time set problem

[Ruben Safir]

On 03/05/2018 03:50 AM, valdis.kletnieks at 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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Ruben Safir]

On 03/05/2018 03:50 AM, valdis.kletnieks at 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

Year 2038 time set problem

[Bernd Petrovitsch]

On Mon, 2018-03-05 at 02:35 +0000, 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 : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180305/c80c7383/attachment.sig>

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[Greg KH]

On Sun, Mar 04, 2018 at 05:25:41PM -0500, valdis.kletnieks at 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 :)

Year 2038 time set problem

[Greg KH]

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

Year 2038 time set problem

[Ruben Safir]

On 03/04/2018 11:15 PM, valdis.kletnieks at 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

Year 2038 time set problem

[Ruben Safir]

On 03/04/2018 11:15 PM, valdis.kletnieks at 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

Year 2038 time set problem

[Ruben Safir]

On 03/04/2018 11:15 PM, valdis.kletnieks at 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

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180304/fbef55f3/attachment.sig>

Year 2038 time set problem

[Alex Arvelaez]

On Mar 4, 2018 10:15 PM, Ruben Safir <ruben@mrbrklyn.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180305/ec668f60/attachment-0001.html>

Year 2038 time set problem

[Ruben Safir]

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

Year 2038 time set problem

[Alex Arvelaez]

On Mar 4, 2018 9:21 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
> On 03/04/2018 05:24 PM, valdis.kletnieks at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180305/f215fb4f/attachment.html>

Year 2038 time set problem

[Ruben Safir]

On 03/04/2018 05:24 PM, valdis.kletnieks at 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

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180304/37041422/attachment.sig>

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

On Sun, 04 Mar 2018 20:47:15 +0000, 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 :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180304/8b1820de/attachment-0001.sig>

Year 2038 time set problem

[Greg KH]

On Sun, Mar 04, 2018 at 03:20:48PM -0500, Ruben Safir wrote:
> On 03/04/2018 01:31 PM, valdis.kletnieks at 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

Year 2038 time set problem

[Greg KH]

On Sun, Mar 04, 2018 at 01:31:04PM -0500, valdis.kletnieks at vt.edu wrote:
> On Sun, 04 Mar 2018 06:59:46 +0000, tali.perry at 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

Year 2038 time set problem

[Alex Arvelaez]

On Mar 4, 2018 3:21 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
>
> On 03/04/2018 01:31 PM, valdis.kletnieks at 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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Regards,

Alex

Year 2038 time set problem

[Ruben Safir]

On 03/04/2018 01:31 PM, valdis.kletnieks at 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

Year 2038 time set problem

[valdis.kletnieks at vt.edu]

On Sun, 04 Mar 2018 06:59:46 +0000, tali.perry at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180304/aa4dbf4b/attachment.sig>

Year 2038 time set problem

[tali.perry at nuvoton.com]

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-request@kernelnewbies.org [mailto:kernelnewbies-request at kernelnewbies.org]
Sent: Thursday, March 1, 2018 7:00 PM
To: kernelnewbies at kernelnewbies.org
Subject: Kernelnewbies Digest, Vol 88, Issue 1

Send Kernelnewbies mailing list submissions to
kernelnewbies at 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-request at kernelnewbies.org

You can reach the person managing the list at
kernelnewbies-owner at 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 <techieth@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>,
kernelnewbies at kernelnewbies.org
Subject: Re: Year 2038 time set problem
Message-ID:
<CAJw2sSAJBKBR33sLdM285LbRfJTWrZwSDJQUnNzYju6QQTErqw@mail.gmail.com>
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 <greg@kroah.com> 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 <greg@kroah.com>
To: techi eth <techieth@gmail.com>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>,
kernelnewbies at kernelnewbies.org
Subject: Re: Year 2038 time set problem
Message-ID: <20180301120414.GB31299@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 at 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
********************************************


===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.