Re: execve(NULL, argv, envp) for nommu?

> Ok, I'll bite. How do you set a signal handler under this regime, since > that needs to pass a function pointer to the syscall? Have a different > function pointer type for when you want a real pointer instead of an > offset pointer? Perhaps label them "near" and "far" pointers, since > there's

Re: execve(NULL, argv, envp) for nommu?

> Ok, I'll bite. How do you set a signal handler under this regime, since > that needs to pass a function pointer to the syscall? Have a different > function pointer type for when you want a real pointer instead of an > offset pointer? Perhaps label them "near" and "far" pointers, since > there's

Re: execve(NULL, argv, envp) for nommu?

On 09/12, Oleg Nesterov wrote: > > On 09/12, Rob Landley wrote: > > > > On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > > > On 09/08, Rob Landley wrote: > > >> > > >> So is exec(NULL, argv, envp) a reasonable thing to want? > > > > > > I think that something like prctl(PR_OPEN_EXE_FILE) which does

Re: execve(NULL, argv, envp) for nommu?

On 09/12, Oleg Nesterov wrote: > > On 09/12, Rob Landley wrote: > > > > On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > > > On 09/08, Rob Landley wrote: > > >> > > >> So is exec(NULL, argv, envp) a reasonable thing to want? > > > > > > I think that something like prctl(PR_OPEN_EXE_FILE) which does

Re: execve(NULL, argv, envp) for nommu?

On 09/12, Rob Landley wrote: > > On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > > On 09/08, Rob Landley wrote: > >> > >> So is exec(NULL, argv, envp) a reasonable thing to want? > > > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > > >

Re: execve(NULL, argv, envp) for nommu?

On 09/12, Rob Landley wrote: > > On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > > On 09/08, Rob Landley wrote: > >> > >> So is exec(NULL, argv, envp) a reasonable thing to want? > > > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > > >

Re: execve(NULL, argv, envp) for nommu?

On 09/12/2017 06:30 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley wrote: >> Your stack has pointers. Your heap has pointers. Your data and bss (once >> initialized) can have pointers. These pointers can be in the middle of >>

Re: execve(NULL, argv, envp) for nommu?

On 09/12/2017 06:30 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley wrote: >> Your stack has pointers. Your heap has pointers. Your data and bss (once >> initialized) can have pointers. These pointers can be in the middle of >> malloc()'ed structures so

Re: execve(NULL, argv, envp) for nommu?

Hi Rob, On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley wrote: > A nommu system doesn't have a memory management unit, so all addresses > are physical addresses. This means two processes can't see different > things at the same address: either they see the same thing or one of >

Re: execve(NULL, argv, envp) for nommu?

Hi Rob, On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley wrote: > A nommu system doesn't have a memory management unit, so all addresses > are physical addresses. This means two processes can't see different > things at the same address: either they see the same thing or one of > them can't see

Re: execve(NULL, argv, envp) for nommu?

On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > On 09/08, Rob Landley wrote: >> >> So is exec(NULL, argv, envp) a reasonable thing to want? > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > dentry_open(current->mm->exe_file->path, O_PATH) > > and returns fd make more

Re: execve(NULL, argv, envp) for nommu?

On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > On 09/08, Rob Landley wrote: >> >> So is exec(NULL, argv, envp) a reasonable thing to want? > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > dentry_open(current->mm->exe_file->path, O_PATH) > > and returns fd make more

Re: execve(NULL, argv, envp) for nommu?

> It's not the performance cost, it's rewriting all the pointers. Which you don't need to do > Without address translation, copying the existing mappings to a new > range requires finding and adjusting every pointer to the old data, No it doesn't. See Minix. When you fork() rather than vfork

Re: execve(NULL, argv, envp) for nommu?

> It's not the performance cost, it's rewriting all the pointers. Which you don't need to do > Without address translation, copying the existing mappings to a new > range requires finding and adjusting every pointer to the old data, No it doesn't. See Minix. When you fork() rather than vfork

Re: execve(NULL, argv, envp) for nommu?

On 09/08, Rob Landley wrote: > > So is exec(NULL, argv, envp) a reasonable thing to want? I think that something like prctl(PR_OPEN_EXE_FILE) which does dentry_open(current->mm->exe_file->path, O_PATH) and returns fd make more sense. Then you can do execveat(fd, "", ...,

Re: execve(NULL, argv, envp) for nommu?

On 09/08, Rob Landley wrote: > > So is exec(NULL, argv, envp) a reasonable thing to want? I think that something like prctl(PR_OPEN_EXE_FILE) which does dentry_open(current->mm->exe_file->path, O_PATH) and returns fd make more sense. Then you can do execveat(fd, "", ...,

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:12 PM, Rob Landley wrote: > On 09/05/2017 08:24 AM, Alan Cox wrote: honoring the suid bit if people feel that way. I just wanna unblock vfork() while still running this code. >> >> Would it make more sense to have a way to promote your vfork into a >> fork when you hit

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:12 PM, Rob Landley wrote: > On 09/05/2017 08:24 AM, Alan Cox wrote: honoring the suid bit if people feel that way. I just wanna unblock vfork() while still running this code. >> >> Would it make more sense to have a way to promote your vfork into a >> fork when you hit

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:24 AM, Alan Cox wrote: >>> anymore. But I'm already _running_ this program. If I could fork() I >>> could already get a second copy of the sucker and call main() again >>> myself if necessary, but I can't, so... > > You can - ptrace 8) Oh I can call clone() with various flags

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:24 AM, Alan Cox wrote: >>> anymore. But I'm already _running_ this program. If I could fork() I >>> could already get a second copy of the sucker and call main() again >>> myself if necessary, but I can't, so... > > You can - ptrace 8) Oh I can call clone() with various flags

Re: execve(NULL, argv, envp) for nommu?

> > anymore. But I'm already _running_ this program. If I could fork() I > > could already get a second copy of the sucker and call main() again > > myself if necessary, but I can't, so... You can - ptrace 8) > > honoring the suid bit if people feel that way. I just wanna unblock > > vfork()

Re: execve(NULL, argv, envp) for nommu?

> > anymore. But I'm already _running_ this program. If I could fork() I > > could already get a second copy of the sucker and call main() again > > myself if necessary, but I can't, so... You can - ptrace 8) > > honoring the suid bit if people feel that way. I just wanna unblock > > vfork()

Re: execve(NULL, argv, envp) for nommu?

CC Oleg, lkml On Tue, Sep 5, 2017 at 9:34 AM, Rob Landley wrote: > For years I've wanted an execve() system call modification that let me > pass a NULL as the first argument to say "re-exec this program please". > Because on nommu you've got to exec something to unblock

Re: execve(NULL, argv, envp) for nommu?

CC Oleg, lkml On Tue, Sep 5, 2017 at 9:34 AM, Rob Landley wrote: > For years I've wanted an execve() system call modification that let me > pass a NULL as the first argument to say "re-exec this program please". > Because on nommu you've got to exec something to unblock vfork(), and > daemons