On 13 February 2018 at 16:38, Eric Blake <ebl...@redhat.com> wrote:
> On 02/13/2018 09:31 AM, Richard Henderson wrote:
>>>
>>> I wonder if there are guest programs that make assumptions about
>>> file descriptor numbers such that it would be worthwhile dup2'ing
>>> the interp_dirfd away from the presumably low number fd it will
>>> get by default into something larger...
>>
>>
>> Hmm.  Using dup2(probe, probe) to test if the new (high) fd itself has not
>> been
>> allocated?
>
>
> fcntl(F_DUPFD[_CLOEXEC]) is smarter than dup2/3, if you plan on atomically
> guaranteeing a dup to a not-in-use fd.
>
> Will dup'ing to a high fd violate assumptions of programs that assume that
> open() and friends favor the next available fd by default, rather than
> having a gap?  (Probably not, but skipping fds is not usual, so it's worth
> asking.)

Well, the idea is that this fd is qemu-internal, so we want the guest
to see that from its point of view the first fd it opens will be 3
if it starts with the usual stdin/stdout/stderr. If we don't move it
then interp_dirfd gets 3 and the guest sees a "gap" from its POV.

(Not being able to hide this qemu-internal fd from the guest properly
is the one awkward part of this patch.)

OTOH, maybe we should just go ahead without weird games with dup2 and
see whether any real code gets confused...

thanks
-- PMM

Reply via email to