netdev - Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

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]

Message-ID: <20090521144739.GF5956@ghostprotocols.net>
Date:	Thu, 21 May 2009 11:47:39 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Paul Moore <paul.moore@...com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Chris Van Hoof <vanhoof@...hat.com>,
	Clark Williams <williams@...hat.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

Em Thu, May 21, 2009 at 10:16:17AM -0400, Paul Moore escreveu:
> On Wednesday 20 May 2009 07:06:52 pm Arnaldo Carvalho de Melo wrote:
> > Meaning receive multiple messages, reducing the number of syscalls and
> > net stack entry/exit operations.
> 
> NOTE: adding the LSM list to the CC line

thanks!
 
> If this approach is accepted I wonder if it would also make sense to move the 
> security_socket_recvmsg() hook out of __sock_recvmsg and into the callers.  I 
> personally can't see a reason why we would need to call into the LSM for each 
> message in the case of the new recvmmsg() syscall.  The downside is that there 
> is now some code duplication (although we are only talking duplicating ~three 
> lines of code) but the upside is that we wont end up calling into the LSM for 
> each of the messages when recvmmsg() is called which seems to fit well with 
> the performance oriented nature of the new syscall.

Agreed that we must do this earlier to avoind vlen calls to
security_socket_recvmsg, but there are many callers of sock_recvmsg...

Also shouldn't recvmmsg have a different LSM hook? It doesn't look right
at first sight to reuse security_socket_recvmsg, as we now are passing
many msghdrs and sockaddrs, etc.

If security_socket_recvmsg receives the msg and inspects it, I think
fully inspecting the mmsg and vlen can be something LSM policies can be
interested in inspecting too, no?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html