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

> 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

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

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

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

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

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

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

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

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