mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] accept4: don't fall back to accept if we got unknown flags
Date: Mon, 27 Feb 2023 18:53:22 -0500	[thread overview]
Message-ID: <20230227235322.GI4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <80d29e1656fea652867bc279be33df00@ispras.ru>

On Tue, Feb 28, 2023 at 02:51:42AM +0300, Alexey Izbyshev wrote:
> On 2023-02-28 02:42, Alexey Izbyshev wrote:
> >On 2023-02-28 01:38, Rich Felker wrote:
> >>On Mon, Feb 27, 2023 at 10:46:54PM +0300, Alexey Izbyshev wrote:
> >>>accept4 emulation via accept ignores unknown flags, so it can
> >>>spuriously
> >>>succeed instead of failing (or succeed without doing the
> >>>action implied
> >>>by an unknown flag if it's added in a future kernel). Worse, unknown
> >>>flags trigger the fallback code even on modern kernels if the real
> >>>accept4 syscall returns EINVAL, because this is
> >>>indistinguishable from
> >>>socketcall returning EINVAL due to lack of accept4 support.
> >>>Fix this by
> >>>always propagating the syscall attempt failure if unknown flags are
> >>>present.
> >>>
> >>>The behavior is still not ideal on old kernels lacking accept4
> >>>on arches
> >>>with socketcall, where failing with ENOSYS instead of EINVAL
> >>>returned by
> >>>socketcall would be preferable, but at least modern kernels are now
> >>>fine.
> >>
> >>Can you clarify what you mean about ENOSYS vs EINVAL here? I'm not
> >>following.
> >>
> >Sorry for confusion, I meant the following. On arches with socketcall,
> >if a program running on an old kernel that doesn't support accept4 in
> >any form calls accept4 with unknown flags, musl's accept4 will fail
> >with EINVAL after this patch. But the reason of failure remains
> >unclear to the programmer: is it because some flag is not supported or
> >because accept4 is not supported at all? So I thought it'd be better
> >to fail with ENOSYS in this case instead, although I don't know a good
> >way to do that: the EINVAL ambiguity exists at socketcall level too,
> >so testing whether the kernel's socketcall supports __SC_accept4 or
> >not would probably involve calling it with known-good arguments on a
> >separately created socket, and I certainly don't propose to do that.
> >
> >On the other hand, it could be argued that a function that can emulate
> >a certain baseline feature set of another function shouldn't fail with
> >ENOSYS at all because the real function would never do that. The two
> >cleanest options for possibly-not-supported functions seem to be
> >either always failing with ENOSYS if the kernel doesn't support the
> >syscall or failing with a reasonable error if the caller requests
> >something unsupported by the emulation. And I think accept4 satisfies
> >the latter with this patch.
> 
> But actually it doesn't. The error should always be EINVAL in case
> of unknown flags for that, but the patch propagates ENOSYS on arches
> without socketcall.

Yeah, I was just about to say that. I think that's wrong. The patch
should be something like:

+       if (flg & ~(SOCK_CLOEXEC|SOCK_NONBLOCK)) return __syscall_ret(-EINVAL);

or explicitly assigning to errno.

Rich

  reply	other threads:[~2023-02-27 23:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 19:46 Alexey Izbyshev
2023-02-27 22:38 ` Rich Felker
2023-02-27 23:42   ` Alexey Izbyshev
2023-02-27 23:51     ` Alexey Izbyshev
2023-02-27 23:53       ` Rich Felker [this message]
2023-02-28 17:21     ` Rich Felker
2023-02-28 17:25       ` Rich Felker
2023-02-28 20:15         ` Alexey Izbyshev
2023-02-28 20:51           ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230227235322.GI4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).