On Mon, Nov 25, 2013 at 11:04:28AM +0100, Michael Holzheu wrote: > On Fri, 22 Nov 2013 05:34:03 -0800 > ebiederm at xmission.com (Eric W. Biederman) wrote: > > > Vivek Goyal <vgoyal at redhat.com> writes: > > > >> There is also a huge missing piece of this in that your purgatory is not > > >> checking a hash of the loaded image before jumping too it. Without that > > >> this is a huge regression at least for the kexec on panic case. We > > >> absolutely need to check that the kernel sitting around in memory has > > >> not been corrupted before we let it run very far. > > > > > > Agreed. This should not be hard. It is just a matter of calcualting > > > digest of segments. I will store it in kimge and verify digest again > > > before passing control to control page. Will fix it in next version. > > > > Nak. The verification needs to happen in purgatory. > > > > The verification needs to happen in code whose runtime environment is > > does not depend on random parts of the kernel. Anything else is a > > regression in maintainability and reliability. > > Hello Vivek, > > Just to be sure that you have not forgotten the following s390 detail: > > On s390 we first call purgatory with parameter "0" for doing the > checksum test. If this fails, we can have as backup solution our > traditional stand-alone dump. In case tha checksum test was ok, > we call purgatory a second time with parameter "1" which then > starts kdump. > > Could you please ensure that this mechanism also works after > your rework. Hi Michael, All that logic in in arch dependent portion of s390? If yes, I am not touching any arch dependent part of s390 yet and only doing implementation of x86. Generic changes should be usable by s390 and you should be able to do same thing there. Though we are still detating whether segment checksum verification logic should be part of purgatory or core kernel. Thanks Vivek
