Re: [PATCH] linux-user: Drop unnecessary check in dup3 syscall

[Peter Maydell]

On Fri, 24 Apr 2020 at 22:33, Eric Blake <address@hidden> wrote:
> I don't think this is quite correct.  target_to_host_bitmask() silently
> ignores unknown bits, and a user that was relying on bit 0x40000000 to
> cause an EINVAL will not fail with this change (unless bit 0x40000000
> happens to be one of the bits translated by fcntl_flags_tbl).  The
> open() syscall is notorious for ignoring unknown bits rather than
> failing with EINVAL, and it is has come back to haunt kernel developers;
> newer syscalls like dup3() learned from the mistake, and we really do
> want to catch unsupported bits up to make it easier for future kernels
> to define meanings to those bits without them being silently swallowed
> when run on older systems that did not know what those bits meant.

The other reason linux-user sometimes has this sort of manual
check of input values is that it can affect which errno value
is returned if a call has multiple wrong things (eg a bad
address to a pointer parameter and a bad flags value), and some
test suites care about the difference. I'm not sure that's the
case here, though. I didn't write out my reasoning back in
2017 when I made this page and don't remember it now, but my
guess is that it's just that dup3 is only supposed
to permit O_CLOEXEC, not any of the other flags that the
fcntl_flags_tbl permits and translates.

thanks
-- PMM