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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
> >
> > 	dentry_open(current->mm->exe_file->path, O_PATH)
> >
> > and returns fd make more sense.
> >
> > Then you can do execveat(fd, "", ..., AT_EMPTY_PATH).
> I'm all for it? That sounds like a cosmetic difference, a more verbose
> way of achieving the same outcome.

Simpler to implement. Something like the (untested) patch below. Not sure
it is correct, not sure it is good idea, etc.

> (Of course now you've got a filehandle you can read xattrs and such
> through from otherwise jailed contexts letting you do things you
> couldn't necessarily do before,

I can be easily wrong, this is not my area, but afaics no. Note that
you get the FMODE_PATH file (see O_PATH), you can do almost nothing
with it.

So. IIUC with this patch you can do

	fd = prctl(PR_OPEN_EXE_FILE);

	execveat(fd, "", NULL, NULL, AT_EMPTY_PATH);

and execveat should succeed even if the binary was unlinked/renamed in

otoh it should fail if, say, you do "chmod a-x exename" in between.

However. This won't work after chroot() so I am not sure this solves your

> but I assume you know the security
> implications of that more than I do.

Unlikely ;)

> > But to be honest, I can't understand the problem, because I know nothing
> > about nommu.
> >
> > You need to unblock parent sleeping in vfork(), and you can't do another
> > fork (I don't undestand why).
> 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 that address (due to a range register making it).

Yes, yes, I understand, and thanks for your detailed explanation...

> > Perhaps the child can create another thread? The main thread can exit
> > after that and unblock the parent. Or perhaps even something like
> > clone(CLONE_VM | CLONE_PARENT), I dunno...
> Launching a new thread doesn't unblock the parent.

Well, this doesn't really matter, but see above, the main thread can exit
after that. This should unblock the parent.

> And even without that, we're still in the "vfork but add concurrency"
> territory. Your threads don't have their own independent mappings,

Of course!

Just I misinterpreted your initial email as if this is fine for your
use-case, and all you need is unblock the parent and nothing else.


--- x/kernel/sys.c
+++ x/kernel/sys.c
@@ -2183,6 +2183,40 @@ static int propagate_has_child_subreaper(struct task_struct *p, void *data)
 	return 1;
+static int open_mm_exe_file(void)
+	struct file *exe_file, *file;
+	struct path *path;
+	int fd = -ENOENT;
+	exe_file = get_mm_exe_file(current->mm);
+	if (!exe_file)
+		goto out;
+	path = &exe_file->f_path;
+	if (!path->dentry)
+		goto put_exe_file;
+	fd = get_unused_fd_flags(O_CLOEXEC); // flags?
+	if (fd < 0)
+		goto put_exe_file;
+	file = dentry_open(path, O_PATH, current_cred());
+	if (IS_ERR(file)) {
+		put_unused_fd(fd);
+		fd = PTR_ERR(file);
+		goto put_exe_file;
+	}
+	path_get(path);
+	fd_install(fd, file);
+	fput(exe_file);
+	return fd;
 SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 		unsigned long, arg4, unsigned long, arg5)
@@ -2196,6 +2230,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 	error = 0;
 	switch (option) {
+		error = open_mm_exe_file();
+		break;
 		if (!valid_signal(arg2)) {
 			error = -EINVAL;

To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux