lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 13 Jul 2011 13:19:30 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>, ebiederm@...ssion.com,
	hbabu@...ibm.com, mahesh@...ux.vnet.ibm.com,
	oomichi@....nes.nec.co.jp, horms@...ge.net.au,
	heiko.carstens@...ibm.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [patch 0/9] kdump: Patch series for s390 support

On Wed, Jul 13, 2011 at 06:59:50PM +0200, Michael Holzheu wrote:
> On Wed, 2011-07-13 at 18:46 +0200, Martin Schwidefsky wrote:
> > On Wed, 13 Jul 2011 12:02:39 -0400
> > Vivek Goyal <vgoyal@...hat.com> wrote:
> > > So in case of stand alone dump, you save the calculated checksum of
> > > kdump kernel at disk and not in memory? And then calculate the checksum
> > > of memory image of kdump kernel and decide whether kdump kenrel is 
> > > corrupted or not?
> > > 
> > > If yes, this sounds more reliable as checksum of kernel is stored on
> > > some disk/tape.
> > 
> > No, the checksum for the purgatory code is stored in memory. If the purgatory
> > code is corrupted you would have to corrupt the checksum in a very specific
> > way as well to make it fail. 
> 
> Currently we store the checksums for the loaded *kexec segments* in
> memory at the end of kexec_load(). The stand-alone dump tools also
> calculate the checksums for all segments and compare them with the
> stored checksums. The dump tools can do that because we have meminfos
> for all segments. A meminfo element contains:
> * address of memory chunk
> * size of memory chunk
> * checksum of memory chunk (calculated at the end of kexec_load()

So this does not seem to be very different from what kexec and purgatory
is doing on x86. So why not simply reuse that and if checksum fails
jump to stand alone kernel. Why to duplicate all the checksum logic
in stand alone dump tools.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ