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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Mar 2007 18:20:14 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Ian Campbell" <Ian.Campbell@...source.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 3/16/07, Ian Campbell <Ian.Campbell@...source.com> wrote:
> 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.

Right, that's how it is supposed to work. But there are unfortunately
differences between the architecture-specific implementations in the
kexec-tools code. So the x86_64 version of kexec-tools behaves
different compared to the i386 version.

For instance, x86_64 passes some acpi parameter on the command line to
the crash kernel, but i386 does not. This may or may not be needed.
There are differences like that or smaller sprinkled all over the
place.

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