netdev - Re: [PATCH net-next] packet: allow MSG

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 24 Feb 2023 14:01:23 +0100
From:   Eric Dumazet <edumazet@...gle.com>
To:     David Lamparter <equinox@...c24.net>
Cc:     Jens Axboe <axboe@...nel.dk>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH net-next] packet: allow MSG_NOSIGNAL in recvmsg

On Fri, Feb 24, 2023 at 1:02 PM David Lamparter <equinox@...c24.net> wrote:
>
> On Fri, Feb 24, 2023 at 11:26:27AM +0100, Eric Dumazet wrote:
> > On Fri, Feb 24, 2023 at 8:18 AM David Lamparter <equinox@...c24.net> wrote:
> [...]
> > > packet_recvmsg() whitelists a bunch of MSG_* flags, which notably does
> > > not include MSG_NOSIGNAL.  Unfortunately, io_uring always sets
> > > MSG_NOSIGNAL, meaning AF_PACKET sockets can't be used in io_uring
> > > recvmsg().
> >
> > This is odd... I think MSG_NOSIGNAL flag has a meaning for sendmsg()
> > (or write sides in general)
> >
> > EPIPE is not supposed to be generated at the receiving side ?
>
> I would agree, but then again the behavior is inconsistent between
> socket types.  (AF_INET6, SOCK_RAW, ...) works fine with
> io_uring/MSG_NOSIGNAL, meanwhile setting MSG_NOSIGNAL on (AF_PACKET,
> SOCK_RAW, ...) gives EINVAL.
>
> Just to get consistency, MSG_NOSIGNAL might be worth ignoring in
> AF_PACKET recvmsg?  Independent of dropping it from io_uring...
>

Probably because rawv6_recvmsg() never bothered to reject unknown flags.
(Maybe the reason for that was that RAW sockets were privileged ones
back in linux-2.6)
It is too late to add a check there, it might break some applications
mistakenly adding MSG_NOSIGNAL (or any currently ignored bits)

Consistency would be to make sure no recvmsg() handler pretends
MSG_NOSIGNAL has a meaning.

Your patch would prevent us using this bit for a future purpose in af_packet.


> > So I would rather make io_uring slightly faster :
> [...]
> > -       sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
> > +       sr->msg_flags = READ_ONCE(sqe->msg_flags);