Re: [gpfsug-discuss] gpfs 4.2.3.6 stops workingwithkernel3.10.0-862.2.3.el7

[Stephen Ulmer]

> On May 15, 2018, at 11:55 PM, Stijn De Weirdt  wrote:
> 
> hi stephen,
> 
>> There isn’t a flaw in that argument, but where the security experts
>> are concerned there is no argument.
> we have gpfs clients hosts where users can login, we can't update those.
> that is a certain worry.

The original statement from Marc was about dedicated hardware for storage 
and/or file serving. If that’s not the use case, then neither his logic nor my 
support of it apply. 


>> 
>> Apparently this time Red Hat just told all of their RHEL 7.4
>> customers to upgrade to RHEL 7.5, rather than back-porting the
>> security patches. So this time the retirement to upgrade
>> distributions is much worse than normal.
> there's no 'this time', this is the default rhel support model. only
> with EUS you get patches for non-latest minor releases.
> 
> stijn
> 

You are correct! I did a quick check and most of my customers are enterprise-y, 
and many of them seem to have EUS. I thought it was standard, but it is not.  I 
could be mixing Red Hat up with another Linux vendor at this point…


Liberty,

-- 
Stephen

___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] gpfs 4.2.3.6 stops workingwithkernel3.10.0-862.2.3.el7

[Stijn De Weirdt]

hi stephen,

> There isn’t a flaw in that argument, but where the security experts
> are concerned there is no argument.
we have gpfs clients hosts where users can login, we can't update those.
that is a certain worry.

> 
> Apparently this time Red Hat just told all of their RHEL 7.4
> customers to upgrade to RHEL 7.5, rather than back-porting the
> security patches. So this time the retirement to upgrade
> distributions is much worse than normal.
there's no 'this time', this is the default rhel support model. only
with EUS you get patches for non-latest minor releases.

stijn

> 
> 
> 
> ___ gpfsug-discuss
> mailing list gpfsug-discuss at spectrumscale.org 
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
> 
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Re: [gpfsug-discuss] gpfs 4.2.3.6 stops workingwithkernel3.10.0-862.2.3.el7

[Stephen Ulmer]

There isn’t a flaw in that argument, but where the security experts are 
concerned there is no argument.

Apparently this time Red Hat just told all of their RHEL 7.4 customers to 
upgrade to RHEL 7.5, rather than back-porting the security patches. So this 
time the retirement to upgrade distributions is much worse than normal.

-- 
Stephen



> On May 15, 2018, at 5:46 PM, Marc A Kaplan  wrote:
> 
> Kevin, that seems to be a good point.  
> 
> IF you have dedicated hardware to acting only as a storage and/or file 
> server, THEN neither meltdown nor spectre should not be a worry.   
> 
> BECAUSE meltdown and spectre are just about an adversarial process spying on 
> another process or kernel memory.  IF we're not letting any potential 
> adversary run her code on our file server, what's the exposure?
>   
> NOW, let the security experts tell us where the flaw is in this argument...
> 
> 
> 
> From:"Buterbaugh, Kevin L" 
> To:gpfsug main discussion list 
> Date:05/15/2018 06:12 PM
> Subject:Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working
> withkernel3.10.0-862.2.3.el7
> Sent by:gpfsug-discuss-boun...@spectrumscale.org
> 
> 
> 
> All, 
> 
> I have to kind of agree with Andrew … it seems that there is a broad range of 
> takes on kernel upgrades … everything from “install the latest kernel the day 
> it comes out” to “stick with this kernel, we know it works.”
> 
> Related to that, let me throw out this question … what about those who 
> haven’t upgraded their kernel in a while at least because they’re concerned 
> with the negative performance impacts of the meltdown / spectre patches???  
> So let’s just say a customer has upgraded the non-GPFS servers in their 
> cluster, but they’ve left their NSD servers unpatched (I’m talking about the 
> kernel only here; all other updates are applied) due to the aforementioned 
> performance concerns … as long as they restrict access (i.e. who can log in) 
> and use appropriate host-based firewall rules, is their some risk that they 
> should be aware of?
> 
> Discuss.  Thanks!
> 
> Kevin
> 
> On May 15, 2018, at 4:45 PM, Andrew Beattie  > wrote:
> 
> this thread is mildly amusing, given we regularly get customers asking why we 
> are dropping support for versions of linux
> that they "just can't move off"
>  
>  
> Andrew Beattie
> Software Defined Storage  - IT Specialist
> Phone: 614-2133-7927
> E-mail: abeat...@au1.ibm.com 
>  
>  
> - Original message -
> From: Stijn De Weirdt  >
> Sent by: gpfsug-discuss-boun...@spectrumscale.org 
> 
> To: gpfsug-discuss@spectrumscale.org 
> Cc:
> Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel 
> 3.10.0-862.2.3.el7
> Date: Wed, May 16, 2018 5:35 AM
>  
> so this means running out-of-date kernels for at least another month? oh
> boy...
> 
> i hope this is not some new trend in gpfs support. othwerwise all RHEL
> based sites will have to start adding EUS as default cost to run gpfs
> with basic security compliance.
> 
> stijn
> 
> 
> On 05/15/2018 09:02 PM, Felipe Knop wrote:
> > All,
> >
> > Validation of RHEL 7.5 on Scale is currently under way, and we are
> > currently targeting mid June to release the PTFs on 4.2.3 and 5.0 which
> > will include the corresponding fix.
> >
> > Regards,
> >
> >   Felipe
> >
> > 
> > Felipe Knop k...@us.ibm.com 
> > 
> > GPFS Development and Security
> > IBM Systems
> > IBM Building 008
> > 2455 South Rd, Poughkeepsie, NY 12601
> > (845) 433-9314  T/L 293-9314
> >
> >
> >
> >
> >
> > From: Ryan Novosielski >
> > To: gpfsug main discussion list  > >
> > Date: 05/15/2018 12:56 PM
> > Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel
> > 3.10.0-862.2.3.el7
> > Sent by: gpfsug-discuss-boun...@spectrumscale.org 
> > 
> >
> >
> >
> > I know these dates can move, but any vague idea of a timeframe target for
> > release (this quarter, next quarter, etc.)?
> >
> > Thanks!
> >
> > --
> > 
> > || \\UTGERS,
> > |---*O*---
> > ||_// the State  | Ryan Novosielski - novos...@rutgers.edu 
> > 
> > || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
> > ||  \\of NJ  | Office of Advanced Research Computing - MSB
> > C630, Newark
> >  `'
> >
> >> On May 14, 2018, at 9:30 AM, Felipe Knop  >> 

Re: [gpfsug-discuss] gpfs 4.2.3.6 stops workingwithkernel3.10.0-862.2.3.el7

[Aaron Knister]

The one thing that comes to mind is if you're able to affect some 
unprivileged process on the NSD servers. Let's say there's a daemon that 
listens on a port but runs as an unprivileged user in which a 
vulnerability appears (lets say a 0-day remote code execution bug). One 
might be tempted to ignore that vulnerability for one reason or another 
but you couple that with something like meltdown/spectre and in *theory* 
you could do something like sniff ssh key material and get yourself on 
the box. In principle I agree with your argument but I've find that when 
one accepts and justifies a particular risk it can become easy to 
remember which vulnerability risks you've accepted and end up more 
exposed than one may realize.


Still, the above scenario is low risk (but potentially very high 
impact), though :)


-Aaron

On 5/15/18 6:46 PM, Marc A Kaplan wrote:

Kevin, that seems to be a good point.

IF you have dedicated hardware to acting only as a storage and/or file 
server, THEN neither meltdown nor spectre should not be a worry.


BECAUSE meltdown and spectre are just about an adversarial process 
spying on another process or kernel memory.  IF we're not letting any 
potential adversary run her code on our file server, what's the exposure?


NOW, let the security experts tell us where the flaw is in this argument...



From: "Buterbaugh, Kevin L" 
To: gpfsug main discussion list 
Date: 05/15/2018 06:12 PM
Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working   
  withkernel        3.10.0-862.2.3.el7

Sent by: gpfsug-discuss-boun...@spectrumscale.org




All,

I have to kind of agree with Andrew … it seems that there is a broad 
range of takes on kernel upgrades … everything from “install the latest 
kernel the day it comes out” to “stick with this kernel, we know it works.”


Related to that, let me throw out this question … what about those who 
haven’t upgraded their kernel in a while at least because they’re 
concerned with the negative performance impacts of the meltdown / 
spectre patches???  So let’s just say a customer has upgraded the 
non-GPFS servers in their cluster, but they’ve left their NSD servers 
unpatched (I’m talking about the kernel only here; all other updates are 
applied) due to the aforementioned performance concerns … as long as 
they restrict access (i.e. who can log in) and use appropriate 
host-based firewall rules, is their some risk that they should be aware of?


Discuss.  Thanks!

Kevin

On May 15, 2018, at 4:45 PM, Andrew Beattie <_abeat...@au1.ibm.com_ 
> wrote:


this thread is mildly amusing, given we regularly get customers asking 
why we are dropping support for versions of linux

that they "just can't move off"


*Andrew Beattie*
*Software Defined Storage  - IT Specialist*
*Phone: *614-2133-7927
*E-mail: *_abeat...@au1.ibm.com_ 


- Original message -
From: Stijn De Weirdt <_stijn.deweirdt@ugent.be_ 
>
Sent by: _gpfsug-discuss-bounces@spectrumscale.org_ 

To: _gpfsug-discuss@spectrumscale.org_ 


Cc:
Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel 
3.10.0-862.2.3.el7

Date: Wed, May 16, 2018 5:35 AM

so this means running out-of-date kernels for at least another month? oh
boy...

i hope this is not some new trend in gpfs support. othwerwise all RHEL
based sites will have to start adding EUS as default cost to run gpfs
with basic security compliance.

stijn


On 05/15/2018 09:02 PM, Felipe Knop wrote:
 > All,
 >
 > Validation of RHEL 7.5 on Scale is currently under way, and we are
 > currently targeting mid June to release the PTFs on 4.2.3 and 5.0 which
 > will include the corresponding fix.
 >
 > Regards,
 >
 >   Felipe
 >
 > 
 > Felipe Knop _k...@us.ibm.com_ 
 > GPFS Development and Security
 > IBM Systems
 > IBM Building 008
 > 2455 South Rd, Poughkeepsie, NY 12601
 > (845) 433-9314  T/L 293-9314
 >
 >
 >
 >
 >
 > From: Ryan Novosielski <_novosirj@rutgers.edu_ 
>
 > To: gpfsug main discussion list <_gpfsug-discuss@spectrumscale.org_ 
>

 > Date: 05/15/2018 12:56 PM
 > Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel
 >             3.10.0-862.2.3.el7
 > Sent by: _gpfsug-discuss-bounces@spectrumscale.org_ 


 >
 >
 >
 > I know these dates can move, but any vague idea of a timeframe target for
 > release (this quarter, next quarter, etc.)?
 >
 > Thanks!
 >
 > --
 > 
 > || \\UTGERS,
 > |---*O*---
 > ||_// the State  |         Ryan Novosielski - _novosirj@rutgers.edu_ 

 > 

Re: [gpfsug-discuss] gpfs 4.2.3.6 stops workingwithkernel3.10.0-862.2.3.el7

[Marc A Kaplan]

Kevin, that seems to be a good point. 

IF you have dedicated hardware to acting only as a storage and/or file 
server, THEN neither meltdown nor spectre should not be a worry. 

BECAUSE meltdown and spectre are just about an adversarial process spying 
on another process or kernel memory.  IF we're not letting any potential 
adversary run her code on our file server, what's the exposure?
 
NOW, let the security experts tell us where the flaw is in this 
argument...



From:   "Buterbaugh, Kevin L" 
To: gpfsug main discussion list 
Date:   05/15/2018 06:12 PM
Subject:Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel 
3.10.0-862.2.3.el7
Sent by:gpfsug-discuss-boun...@spectrumscale.org



All, 

I have to kind of agree with Andrew … it seems that there is a broad range 
of takes on kernel upgrades … everything from “install the latest kernel 
the day it comes out” to “stick with this kernel, we know it works.”

Related to that, let me throw out this question … what about those who 
haven’t upgraded their kernel in a while at least because they’re 
concerned with the negative performance impacts of the meltdown / spectre 
patches???  So let’s just say a customer has upgraded the non-GPFS servers 
in their cluster, but they’ve left their NSD servers unpatched (I’m 
talking about the kernel only here; all other updates are applied) due to 
the aforementioned performance concerns … as long as they restrict access 
(i.e. who can log in) and use appropriate host-based firewall rules, is 
their some risk that they should be aware of?

Discuss.  Thanks!

Kevin

On May 15, 2018, at 4:45 PM, Andrew Beattie  wrote:

this thread is mildly amusing, given we regularly get customers asking why 
we are dropping support for versions of linux
that they "just can't move off"
 
 
Andrew Beattie
Software Defined Storage  - IT Specialist
Phone: 614-2133-7927
E-mail: abeat...@au1.ibm.com
 
 
- Original message -
From: Stijn De Weirdt 
Sent by: gpfsug-discuss-boun...@spectrumscale.org
To: gpfsug-discuss@spectrumscale.org
Cc:
Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel 
3.10.0-862.2.3.el7
Date: Wed, May 16, 2018 5:35 AM
 
so this means running out-of-date kernels for at least another month? oh
boy...

i hope this is not some new trend in gpfs support. othwerwise all RHEL
based sites will have to start adding EUS as default cost to run gpfs
with basic security compliance.

stijn


On 05/15/2018 09:02 PM, Felipe Knop wrote:
> All,
>
> Validation of RHEL 7.5 on Scale is currently under way, and we are
> currently targeting mid June to release the PTFs on 4.2.3 and 5.0 which
> will include the corresponding fix.
>
> Regards,
>
>   Felipe
>
> 
> Felipe Knop k...@us.ibm.com
> GPFS Development and Security
> IBM Systems
> IBM Building 008
> 2455 South Rd, Poughkeepsie, NY 12601
> (845) 433-9314  T/L 293-9314
>
>
>
>
>
> From: Ryan Novosielski 
> To: gpfsug main discussion list 
> Date: 05/15/2018 12:56 PM
> Subject: Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working withkernel
> 3.10.0-862.2.3.el7
> Sent by: gpfsug-discuss-boun...@spectrumscale.org
>
>
>
> I know these dates can move, but any vague idea of a timeframe target 
for
> release (this quarter, next quarter, etc.)?
>
> Thanks!
>
> --
> 
> || \\UTGERS,
> |---*O*---
> ||_// the State  | Ryan Novosielski - novos...@rutgers.edu
> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS 
Campus
> ||  \\of NJ  | Office of Advanced Research Computing - MSB
> C630, Newark
>  `'
>
>> On May 14, 2018, at 9:30 AM, Felipe Knop  wrote:
>>
>> All,
>>
>> Support for RHEL 7.5 and kernel level 3.10.0-862 in Spectrum Scale is
> planned for upcoming PTFs on 4.2.3 and 5.0. Since code changes are 
needed
> in Scale to support this kernel level, upgrading to one of those 
upcoming
> PTFs will be required in order to run with that kernel.
>>
>> Regards,
>>
>> Felipe
>>
>> 
>> Felipe Knop  k...@us.ibm.com
>> GPFS Development and Security
>> IBM Systems
>> IBM Building 008
>> 2455 South Rd, Poughkeepsie, NY 12601
>> (845) 433-9314 T/L 293-9314
>>
>>
>>
>> Andi Rhod Christiansen ---05/14/2018 08:15:25 AM---You are
> welcome. I see your concern but as long as IBM has not released spectrum
> scale for 7.5 that
>>
>> From:  Andi Rhod Christiansen 
>> To:  gpfsug main discussion list 
>> Date:  05/14/2018 08:15 AM
>> Subject:  Re: [gpfsug-discuss] gpfs 4.2.3.6 stops working with kernel
> 3.10.0-862.2.3.el7
>> Sent by:  gpfsug-discuss-boun...@spectrumscale.org
>>
>>
>>
>>
>> You are welcome.
>>
>> I see your concern but as long as IBM has not released spectrum scale 
for
> 7.5 that