linux-kernel - Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86

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]

Message-Id: <1174035001.28658.61.camel@localhost.localdomain>
Date:	Fri, 16 Mar 2007 08:50:01 +0000
From:	Ian Campbell <Ian.Campbell@...Source.com>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	Horms <horms@...ge.net.au>, Vivek Goyal <vgoyal@...ibm.com>,
	fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org
Subject: Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle
	x86_64 dumps

On Fri, 2007-03-16 at 16:59 +0900, Magnus Damm wrote:
> On 3/16/07, Ian Campbell <Ian.Campbell@...source.com> wrote:
> > On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> > > Right. And maybe it's a good idea to make sure that this feature is
> > > actually supported by kexec-tools before adding code to the kernel?
> >
> > I sent patches to the fastboot list at the same time I sent these ones
> > to support differences in the underlying hypervisor architecture in the
> > tools.
> 
> Oh, that's good news. I have not seen them yet...
> 
> > They haven't appeared in the archives yet so I fear they have gone
> > astray. I'll resend when I get to the office in a bit.
> 
> ... so please resend.
> 
> We've just frozen the kexec-tools-testing tree for an upcoming
> release, but if you resend soon and your patches are trivial you may
> be able to talk us into merging your changes before the release..

Will resend in about an hour.

> > > My gut feeling about this is that you are begging for trouble. The
> > > kexec/kdump solution is fragile just by itself, and trying to go
> > > between architectures is just going to be painful.
> >
> > It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> > makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> > originally I'm not so convinced it makes sense in the native case but I
> > see no reason to outlaw it (people get to keep both pieces etc...)
> 
> For kexec I think it is just fine. But for kdump, are you sure things
> will work out ok? There are some differences between the i386 and
> x86_64 kexec-tools code and I wonder if feeding i386 info into an
> x86_64 kernel will work properly.

It seems to work fine with Xen. A 32 bit kernel handles the 64 bit dump
just fine, my pre-kdump kernel is 32 bit but it doesn't have much to do
in this case I think.

I don't know about native. My gut feeling is that if the mechanism of
actually kexecing between 64 and 32 bit works then there is no problem
with the crash dump part of the equation.

The crash dump is pretty much opaque to the kernel -- it finds the
headers in memory and exports the relevant pieces via /proc/vmcore. The
crash kernel doesn't really care what those pieces are so long as they
constitute a valid ELF image.

My patch to kexec-tools-testing just changes e_machine to match the type
of the pre-crash system. The dump kernel pays no attention to this field
apart from the one sanity check which my patch from this thread
addresses.

>>From userspace the contents of /proc/vmcore should be identical to what
you would see if you had done a 64->64 dump instead of a 64->32 one. I
don't think it is any different to copying /proc/vmcore to a different
system for analysis so any userspace tools should be able to cope.

Ian.

-
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/