linux-kernel - RE: recvfrom/recvmsg performance and CONFIG_HARDENED

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] [day] [month] [year] [list]

Date:   Tue, 10 Dec 2019 10:21:49 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...capital.net>
CC:     Eric Dumazet <eric.dumazet@...il.com>,
        network dev <netdev@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: recvfrom/recvmsg performance and CONFIG_HARDENED_USERCOPY

From: Andy Lutomirski
> Sent: 09 December 2019 18:43
> 
> > On Dec 9, 2019, at 3:01 AM, David Laight <David.Laight@...lab.com> wrote:
> >
> > From: Eric Dumazet
> >> Sent: 06 December 2019 14:22
> > ...
> >> Real question is : Do you actually need to use recvmsg() instead of recvfrom() ?
> >> If recvmsg() provides additional cmsg, this is not surprising it is more expensive.
> >
> > Except I'm not passing in a buffer for it.
> > The reason I'm looking at recvmsg is that I'd like to use recvmmsg it order to
> > read out more than one message from a socket without doing an extra poll().
> > Note that I don't expect there to be a second message most of the time and
> > almost never a third one.
> >
> > Although I think that will only ever 'win' if recvmmsg() called vfs_poll() to find
> > if there was more data to read before doing any of the copy_from_user() etc
> 
> I would suggest a more general improvement: add a -EAGAIN fast path to recvmsg().
> If the socket is nonblocking and has no data to
> read, then there shouldn’t be a need to process the iovec at all.

You don't want to do that for recvmsg() itself.
It will normally only be called if poll() reported data is available.
Actually the MSG_WAITFORONE flag could be used to do a call
to vfs_poll() before the subsequent calls to __sys_recvmsg().
This will work for non-blocking sockets (or even calls with both
MSG_DONTWAIT and MSG_WAITFORONE set).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)