On Thu, 3 Oct 2019 at 13:52, Phelps, Matthew <mphelps at cfa.harvard.edu> wrote: > > On Thu, Oct 3, 2019 at 1:42 PM Jim Perrin <jperrin at centos.org> wrote: > > > > > > > On 10/3/19 1:32 PM, Phelps, Matthew wrote: > > > Forgive me if this has been answered before and I've missed it. > > > > > > This https://access.redhat.com/solutions/2206511 says live kernel > > patches > > > will be available via yum updates as of RHEL 7.7. Is this carried over to > > > CentOS 7.7.1908? > > > > > > > The functionality should be available, but we don't provide patches in > > this way, no. > > What would it take to make this happen? This would be a huge help to those > of us running servers. Not to mention it would make the world a more secure > place :) > > Is it an upstream issue? No SRPMS available? Etc? > > Just trying to understand. I don't follow the centos-devel list. Has this > been discussed there, or elsewhere? > There is a lot to go into making a correct kpatch. You have to determine that you have a working kpatch (you can have one which works on 1% and corrupts 80% and crashes 19%), you have to determine that the patch fixes the problem (you can build patches which should do the right thing but don't), and you have to determine that it doesn't add in some sort of long term corruption of memory/disk/etc. That takes specialized kernel expertise, a large amount of varied hardware to test the patch on, some amount of time, and a very large test suite. You can also only live patch a system so many times and in only certain places. There are just some parts of the kernel which have to be rebooted and others you can put in a patch which works but your performance is going to be 25% of what it was before. There are other places that if you patch.. that is it.. try another and you hardlock. As much as some sites like to call it some sort of panacea for never having to reboot again.. it is really meant to be a tourniquet to air chopter the crash victim to a hospital. They may still not make it... you are just giving them a chance. -- Stephen J Smoogen.