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:	Mon, 18 Aug 2014 13:15:40 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Will Deacon <will.deacon@....com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>,
	David Herrmann <dh.herrmann@...il.com>
Subject: Re: [PATCH 2/2] asm-generic: add memfd_create system call to unistd.h

On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 01:37:36PM +0100, Vivek Goyal wrote:
> > On Tue, Aug 12, 2014 at 12:10:30PM +0100, Will Deacon wrote:
> > > Hmm, so whilst I can easily wire-up the new syscall, it's pretty useless for
> > > anybody other than x86 at the moment. There are a bunch of arch helpers:
> > > 
> > >  arch_kexec_kernel_image_probe
> > >  arch_kexec_kernel_verify_sig
> > >  arch_kexec_kernel_image_load
> > >  arch_kimage_file_post_load_cleanup
> > > 
> > > which are only implemented for x86 (arch/x86/kernel/machine_kexec_64.c),
> > > even though I don't really see what makes them arch-specific as opposed to
> > > file format specific.
> > 
> > Yes, at this point of time, this system call will work only on x86. Agreed
> > that primarily it is file format details which are primarily in arch
> > specific section.
> > 
> > I think that some of the code will become arch independent as other
> > arches start implementing this syscall. 
> > 
> > > 
> > > So this syscall will always fail with -ENOEXEC at the moment. Is it still
> > > worth wiring it up?
> > 
> > I thought that for other arches I have not even defined the syscall. So
> > it probably will fail with -ENOSYS.
> 
> What I meant was, if I wire it into asm-generic/unistd.h then it will return
> -ENOEXEC for architectures using that file (e.g. arm64).
> 
> Patch below, but I don't think it's very useful.
> 

Hi Will,

I have not even defined a syscall number for other arches. IIUC, this
patch will forcibly introduce a syscall number for the new syscall for
arches which use asm-generic/unistd.h.

So question I have is that why should we do it now. One can do it once
somebody enables kexec_file_load() on arm64.

Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So
even on arm64 it must be getting compiled in. But it is not being hooked
up using system call table. So there should not be any way to invoke
syscalll definition. So my understand is that in current form, one can
not invoke kexec_file_load() on arm64. Is that right.

Now I have put one more patch to make compilation of kexec_file_load()
conditional on config option CONFIG_KEXEC_FILE. And this option can
be enabled only on x86_64. That means kexec_file_load() will not even
be compiled in on arm64 (once the patch gets merged). Right now patch
is sitting in andrew's tree.

http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch

Can you please help me understand that why do we need this patch if at
this point of time we are not even fixing a system call number for
kexec_file_load() for arches except x86_64.

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