Re: 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@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

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

[Greg KH]

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

[Jeffrey Walton]

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

[Alex Arvelaez]

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

[Darin Avery]

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

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[valdis . kletnieks]

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

[Ruben Safir]

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

[Ruben Safir]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[Ruben Safir]

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

[Bernd Petrovitsch]

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

[valdis . kletnieks]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[Greg KH]

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

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[Ruben Safir]

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

[Ruben Safir]

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

[Ruben Safir]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[valdis . kletnieks]

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

[Alex Arvelaez]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[Alex Arvelaez]

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

[Ruben Safir]

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

[valdis . kletnieks]

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

[valdis . kletnieks]

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

[Greg KH]

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

[Greg KH]

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

[Alex Arvelaez]

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

[Ruben Safir]

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

[valdis . kletnieks]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Piotr Figiel]

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

[Piotr Figiel]

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)

[Piotr Figiel]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Year 2038 time set problem

[Dave Stevens]

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)

[Greg KH]

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

[valdis . kletnieks]

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

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

[valdis . kletnieks]

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

[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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: 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,  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

[valdis . kletnieks]

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