Re: linux-user: Add option to run `execve`d programs through QEMU

[Richard Henderson <richard.henderson@linaro.org>]

On 11/6/24 23:49, Noah Goldstein wrote:
> On Wed, Nov 6, 2024 at 3:30 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>>
>> On Wed, Nov 6, 2024 at 3:10 PM Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>>>
>>> On 11/6/24 18:13, Noah Goldstein wrote:
>>>> Question about impl regarding handling of `-execfd` with/without a program name.
>>>>
>>>> 1) `-execfd` + program name ie: `qemu -execfd <some_fd> ls -a`.
>>>> 2) `-execfd` without program name i.e: `qemu -execfd <some_fd> -a`.
>>>>
>>>> Do you want to allow both of these? If you want to allow (1), what should
>>>> we use for `argv[0]`/`exec_path`. The program pass ("ls") or
>>>> `readlink(<some_fd>)`?
>>>
>>> The canonical response is, examine the kernel source.
>>> We're not implementing this in a vacuum, you're replicating execveat(2).
>>>
>>> I suspect the answer is (1), to be compared with
>>>
>>>       syscall(__NR_execveat, some_fd, "", &["ls", "-a"], env, AT_EMPTY_PATH);
>>
>> Err, I think the reference for '-execfd' is `fexecve`:
>> https://man7.org/linux/man-pages/man3/fexecve.3.html
>>
>> Which doesn't take a path. So I guess we just interpret the "ls" as
>> argv[0] but not
>> as "exec_path".
> 
> One more point, what should the behavior be if we have
> AT_EXECFD from binfmt-misc?

You mean precedence of AT_EXECFD vs the command-line option?

Arbitrary, since it would be a usage error to have both.  You'd have to do something silly 
with the binfmt-misc rule for that to happen.

Perhaps

static int execfd = -1;
// option processing
// main

     if (execfd < 0) {
         errno = 0;
         execfd = qemu_getauxval(AT_EXECFD);
         if (errno != 0) {
             execfd = open(...);
         }
     }

just because that's a simple change to what's currently present.


r~