linux-kernel - Re: [RFC 08/19] exec: add API specification for execve

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aFDKHhaqB75Qi212@lappy>
Date: Mon, 16 Jun 2025 21:51:26 -0400
From: Sasha Levin <sashal@...nel.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	workflows@...r.kernel.org, tools@...nel.org
Subject: Re: [RFC 08/19] exec: add API specification for execve

On Mon, Jun 16, 2025 at 11:39:31PM +0200, Florian Weimer wrote:
>* Sasha Levin:
>
>> +	KAPI_RETURN("long", "Does not return on success; returns -1 on error")
>> +		.type = KAPI_TYPE_INT,
>> +		.check_type = KAPI_RETURN_ERROR_CHECK,
>> +	KAPI_RETURN_END
>
>Is the -1 part correct?

Maybe :) That's one of the things I wasn't sure about: we're documenting
the execve syscall rather than the function itself. A user calling
execve() will end up with -1 on failure, and errno set with the error
code.

You could argue that it's libc that sets errno and we're trying to spec
the kernel here, not the userspace interface to it.

At the end I managed to lawyer myself into a decision that I liked: I
figured that since klibc is really a kernel library that is merely
packaged seperately from the kernel, it is really a kernel interface,
and so I followed the libc convention.

Open for suggestions...

>Many later errors during execve are not recoverable and result in execve
>succeeding (nominally) and a fatal signal being delivered to the process
>instead.  Not sure if the description covers that.

I was afraid of the "signals" rabit hole: from what I recall, you can
have fatal signals pending past the point of no return but before
execve() completes from both execve() failures as well as external
sources.

There's definitely room for a longer explanation of how all of this
works together.

I'd suggest that we tackle signal specs in the near future, and see how
we can tie those into the rest of the API specs. Right now I'm pretty
unhappy with the vague KAPI_SIGNAL().

>What about the effect of unblocking a parent thread that has vfork'ed?

In my mind it's vfork() that is waiting for the execve to complete (via
wait_for_vfork_done()) rather than execve() actively waking up the
vfork() parent.

We can list it as a side effect of execve()? I suppose that its similar
to something like read() in one process waking up a different process
from epoll_wait(), so we should probably be documenting those as well...

Thanks for the comments!

-- 
Thanks,
Sasha