Messages in this thread | | | From | Meredydd Luff <> | Date | Thu, 2 Aug 2012 10:14:53 +0100 | Subject | Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2) |
| |
On Thu, Aug 2, 2012 at 7:55 AM, Al Viro <viro@zeniv.linux.org.uk> wrote: >> This means you need an x32 version of the function -- execve >> unfortunately is one of the few system calls which require a special x32 >> version (although it's a simple wrapper around sys32_execve). See >> sys_x32_execve. > > I *really* strongly object to doing that thing before we sanitize the > situation with sys_execve().
"That thing" = "creating an x32 entry stub", or "merging execveat() at all"?
(snip) > The thing is, there's essentially no reason to have more than one > implementation. What they are (badly) doing is "we need to find > pt_regs to pass to do_execve(), the thing we are after has to be near > our stack frame, so let's try to get to it that way".
Hang on...it's not just sys_execve that fits that description, is it? You seem to be describing every call that needs a pt_regs parameter, which at a glance is anything with a stub_ or PTREGSCALL in arch/x86/kernel/entry_{32,64}.S. That's: clone, fork, vfork, sigaltstack, iopl, execve, sigreturn, rt_sigreturn, vm86, vm86old. Most of those are handled by a common PTREGSCALL macro, but there are a few that get special treatment (different set on each arch - on x86-64 it's execve and rt_sigreturn ; on i386 it's just clone).
Is there's something special about execve in particular, or do you want to overhaul all the ptregscalls?
Meredydd
| |