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:	Wed, 6 Jan 2010 00:27:48 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	nhorman@...driver.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: packet: option to only pass skb protocol

On Tue, Jan 05, 2010 at 04:13:29PM -0600, Chris Friesen wrote:
> On 01/05/2010 03:42 PM, David Miller wrote:
> > From: "Chris Friesen" <cfriesen@...tel.com>
> > Date: Tue, 05 Jan 2010 15:28:22 -0600
> > 
> >> On 01/05/2010 12:57 PM, Michael S. Tsirkin wrote:
> >>> When sending packets with a packet socket it is often necessary to set
> >>> protocol in msg_name: otherwise the protocol field in the skb will not
> >>> be set correctly.
> >>
> >> What about automatically detecting the protocol from the data being sent
> >> to avoid the necessity of specifying it in the first place?
> > 
> > This limits packet socket usage to only protocols the kernel is aware
> > of, defeating part of the usefulness of the packet socket facility.
> 
> I don't follow.
> 
> If SOCK_RAW packets are being sent, the protocol number is embedded in
> the packet data and the kernel should be able to extract it regardless
> of whether the kernel actually supports it or not.  I see that Michael
> just posted a patch for this.
> 
> If SOCK_DGRAM packets are being sent, then I agree that the app needs to
> pass it down at send time or at bind() time to support protocols of
> which the kernel is not aware.
> 
> While looking at the code I noticed that while the protocol number is
> validated at socket creation time it does not appear to be validated for
> calls to bind() for packet sockets.  Is this intentional?
> 
> As a further question, does it actually make sense to check the protocol
> number at packet socket creation?  It seems like we should be able to
> allow a packet socket to specify arbitrary protocol numbers since the
> kernel doesn't really need to do anything with them.
> 
> Chris

I wouldn't say kernel doesn't really need to do anything with them.

In fact I think currently protocol number affects whether other packet
sockets see the packet in question.  There may be other cases, e.g. if
the device in question is a bridge, the packet gets reinjected in host
stack, so using a silly value for protocol field might interfere with
GRO etc.


-- 
MST
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ