netdev - Re: [PATCHv2 bpf-next 5/5] selftests: bpf: add test for sk

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 26 Mar 2020 14:38:41 -0700
From:   Joe Stringer <joe@...d.net.nz>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Joe Stringer <joe@...d.net.nz>, bpf <bpf@...r.kernel.org>,
        Lorenz Bauer <lmb@...udflare.com>,
        Networking <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Martin Lau <kafai@...com>
Subject: Re: [PATCHv2 bpf-next 5/5] selftests: bpf: add test for sk_assign

On Thu, Mar 26, 2020 at 12:37 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Wed, Mar 25, 2020 at 10:28 PM Joe Stringer <joe@...d.net.nz> wrote:
> >
> > On Wed, Mar 25, 2020 at 7:16 PM Andrii Nakryiko
> > <andrii.nakryiko@...il.com> wrote:
> > >
> > > On Tue, Mar 24, 2020 at 10:58 PM Joe Stringer <joe@...d.net.nz> wrote:
> > > >
> > > > From: Lorenz Bauer <lmb@...udflare.com>
> > > >
> > > > Attach a tc direct-action classifier to lo in a fresh network
> > > > namespace, and rewrite all connection attempts to localhost:4321
> > > > to localhost:1234 (for port tests) and connections to unreachable
> > > > IPv4/IPv6 IPs to the local socket (for address tests).
> > > >
> > > > Keep in mind that both client to server and server to client traffic
> > > > passes the classifier.
> > > >
> > > > Signed-off-by: Lorenz Bauer <lmb@...udflare.com>
> > > > Co-authored-by: Joe Stringer <joe@...d.net.nz>
> > > > Signed-off-by: Joe Stringer <joe@...d.net.nz>
> > > > ---
> >
> > <snip>
> >
> > > > +static void handle_timeout(int signum)
> > > > +{
> > > > +       if (signum == SIGALRM)
> > > > +               fprintf(stderr, "Timed out while connecting to server\n");
> > > > +       kill(0, SIGKILL);
> > > > +}
> > > > +
> > > > +static struct sigaction timeout_action = {
> > > > +       .sa_handler = handle_timeout,
> > > > +};
> > > > +
> > > > +static int connect_to_server(const struct sockaddr *addr, socklen_t len)
> > > > +{
> > > > +       int fd = -1;
> > > > +
> > > > +       fd = socket(addr->sa_family, SOCK_STREAM, 0);
> > > > +       if (CHECK_FAIL(fd == -1))
> > > > +               goto out;
> > > > +       if (CHECK_FAIL(sigaction(SIGALRM, &timeout_action, NULL)))
> > > > +               goto out;
> > >
> > > no-no-no, we are not doing this. It's part of prog_tests and shouldn't
> > > install its own signal handlers and sending asynchronous signals to
> > > itself. Please find another way to have a timeout.
> >
> > I realise it didn't clean up after itself. How about signal(SIGALRM,
> > SIG_DFL); just like other existing tests do?
>
> You have alarm(3), which will deliver SIGALARM later, when other test
> is running. Once you clean up this custom signal handler it will cause
> test_progs to coredump. So still no, please find another way to do
> timeouts.

FWIW I hit this issue and alarm(0) afterwards fixed it up.

That said the SO_SNDTIMEO / SO_RCVTIMEO alternative should work fine
for this use case instead so I'll switch to that, it's marginally
cleaner.