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: <20070316024239.GB10515@in.ibm.com>
Date:	Fri, 16 Mar 2007 08:12:39 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Horms <horms@...ge.net.au>
Cc:	Ian Campbell <Ian.Campbell@...source.com>, hbabu@...ibm.com,
	fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

On Fri, Mar 16, 2007 at 08:48:08AM +0900, Horms wrote:
> On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > On Thu, Mar 15, 2007 at 12:22:57PM +0000, Ian Campbell wrote:
> > > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > > But I think changing this macro might run into issues. It is
> > > > > > being used at few places in kernel, for example while loading
> > > > > > module. This will essentially mean that we allow loading 64bit
> > > > > > x86_64 modules on 32bit i386 systems?
> > > 
> > > Yes, not sure how I missed that fact...
> > > 
> > > > Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
> > > 
> > > For crash kernel only or for regular kexec too?
> > > 
> > 
> > I think for both. One of the possible reasons I think is that one never
> > knows is underlying machine has got 64bit extensions or not. So even if
> > we load the kernel it will never boot. Secondly, we might not be able to
> > handle 64bit address in 32bit kernel/user space?
> 
> Perhaps I am miss-understanding what you are saying, but I do
> recally kexecing from 32->64 and 64->32 bit kernels on x86_64 hardware.
> I can run these checks again if it helps.
> 

Yesterday I tested it. I could kexec from 64->32bit but not vice versa.
kexec-tools itself gave error message.

"Cannot determine the file type of ../x86_64-vmlinux/vmlinux"

I did not investigate deeper but I got a basic question. How will kexec
know that underlying 32bit machine supports 64bit extensions or not? Do
we allow loading 64bit kernel even underlying machine might not support
it?

Probably you can also give it a try. 
 
> > > > So how about something like vmcore_elf_allowed_cross_arch()? Vmcore
> > > > code can continue to check elf_check_arch() and if that fails it can
> > > > invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are
> > > > allowed for vmcore. 
> > > 
> > > Something like this?
> > > 
> > > Ian.
> > > 
> > > ---  
> > > 
> > > Allow i386 crash kernels to handle x86_64 dumps.
> > > 
> > > The specific case I am encountering is kdump under Xen with a 64 bit
> > > hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit
> > > due to the hypervisor but the dump kernel is 32 bit in for maximum
> > > compatibility.
> > > 
> > > It's possibly less likely to be useful in a purely native scenario but
> > > I see no reason to disallow it.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@...source.com>
> > > 
> > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > index d960507..523e109 100644
> > > --- a/fs/proc/vmcore.c
> > > +++ b/fs/proc/vmcore.c
> > > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > >  	/* Do some basic Verification. */
> > >  	if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > >  		(ehdr.e_type != ET_CORE) ||
> > > -		!elf_check_arch(&ehdr) ||
> > > +		!vmcore_elf_check_arch(&ehdr) ||
> > >  		ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > >  		ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > >  		ehdr.e_version != EV_CURRENT ||
> > > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > > index 4dfc9f5..c76737e 100644
> > > --- a/include/asm-i386/kexec.h
> > > +++ b/include/asm-i386/kexec.h
> > > @@ -47,6 +47,9 @@
> > >  /* The native architecture */
> > >  #define KEXEC_ARCH KEXEC_ARCH_386
> > > 
> > > +/* We can also handle crash dumps from 64 bit kernel. */
> > > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > > +
> > 
> > Ideal place for this probably should have been arch dependent crash_dump.h
> > file. But we don't have one and no point introducing one just for this 
> > macro.
> > 
> > This change looks good to me.
> 
> Won't the above change break non i386 archtectures as
> vmcore_elf_check_arch_cross isn't defined for them?
> 

In original patch he has put an arch independent definition in
include/linux/crash_dump.h which will make sure it is not broken on
other architectures.

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