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:	Fri, 6 Jun 2014 16:04:18 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Dave Young <dyoung@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
	ebiederm@...ssion.com, hpa@...or.com, mjg59@...f.ucam.org,
	greg@...ah.com, bp@...en8.de, jkosina@...e.cz, chaowang@...hat.com,
	bhe@...hat.com, akpm@...ux-foundation.org
Subject: Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in
 kernel loading

On Fri, Jun 06, 2014 at 03:37:48PM +0800, Dave Young wrote:
> On 06/05/14 at 11:01am, Vivek Goyal wrote:
> > On Thu, Jun 05, 2014 at 04:31:34PM +0800, Dave Young wrote:
> > 
> > [..]
> > > > +	ret = kexec_file_load(kernel_fd, info.initrd_fd, info.command_line,
> > > > +			info.command_line_len, info.kexec_flags);
> > > 
> > > Vivek,
> > > 
> > > I tried your patch on my uefi test machine, but kexec load fails like below:
> > > 
> > > [root@...alhost ~]# kexec -l /boot/vmlinuz-3.15.0-rc8+ --use-kexec2-syscall
> > > Could not find a free area of memory of 0xa000 bytes ...
> > 
> > Hi Dave,
> > 
> > I think this message is coming from kexec-tools from old loading path. I
> > think somehow new path did not even kick in. I tried above and I got
> > -EBADF as I did not pass initrd. Can you run gdb on kexec and see if
> > you are getting to syscall or run strace.
> 
> Seems I can not reproduce the local hole fail issue but I'm sure it happens
> before the new syscall callback.
> 
> This time I got -ENOEXEC. It's caused by CONFIG_EFI_MIXED=y. In case EFI_MIXED
> 64bit kernel runs on 32bit efi firmware thus XLF_CAN_BE_LOADED_ABOVE_4G is not
> set thus bzImage probe will fail with NOEXEC.

Yep, current bzImage loader only supports loading 64bit image which can
be loaded above 4G.

I am wondering how user space implementation is taking care of it. I guess
we are falling back to 32bit implementation where we use 32bit entry and
assume that bzImage has to be below 4G.

We will have to do similar thing in kernel when 32bit loader comes in.
Compile that in for 64bit kernel and let it handle the case of bzImage
not being loadable above 4G.

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