Message-ID: <20090521151109.GG5956@ghostprotocols.net>
Date:	Thu, 21 May 2009 12:11:09 -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 11:03:26AM -0400, Paul Moore escreveu:
> On Thursday 21 May 2009 10:47:39 am Arnaldo Carvalho de Melo wrote:
> > 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...
> 
> Yeah, like I said there is a downside to this approach, the question is how 
> much do we care about performance and what are we willing to give up for it?  
> I don't know the answer but I thought the question needed to be asked.

Well, if we only check if the process can read from the socket, I also
see no reasons for a new security_socket_recvmmsg nor for checking it
multiple times in recvmmsg, since what changes (the msg) is of no
interest to LSM.
 
> > 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.
> 
> Well, right now the only LSM of the three in the mainline kernel that makes 
> use of the recvmsg hook is SELinux and in SELinux the recvmsg hook really only 
> checks to see if the process can read from the socket - there is no access 
> check against the message itself.  In general, all of the per-packet/message 
> access controls happen below the socket layer in SELinux so I see no reason 
> why we would need to execute the recvmsg hook multiple times for each 
> recvmmsg() syscall.

Agreed
 
> If I'm wrong I'm sure the LSM brain trust will quickly step in ...
> 
> > 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?
> 
> Maybe, but not with what we currently have in-tree.  Perhaps this is a 
> sign/opportunity that we can trim the arguments to security_socket_recvmsg() 
> too?

Perhaps, but up to LSM folks to tell if this was really a case where
passing the msg was something that ended up being overkill.

- 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

Powered by blists - more mailing lists