netdev - Re: [PATCH net-next] tcp: provide SYN headers for passive connections

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:	Tue, 05 May 2015 16:05:35 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	emunson@...mai.com, tom@...bertland.com, linux-api@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tcp: provide SYN headers for passive
 connections

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Sun, 03 May 2015 21:34:46 -0700

> From: Eric Dumazet <edumazet@...gle.com>
> 
> This patch allows a server application to get the TCP SYN headers for
> its passive connections.  This is useful if the server is doing
> fingerprinting of clients based on SYN packet contents.
> 
> Two socket options are added: TCP_SAVE_SYN and TCP_SAVED_SYN.
> 
> The first is used on a socket to enable saving the SYN headers
> for child connections. This can be set before or after the listen()
> call.
> 
> The latter is used to retrieve the SYN headers for passive connections,
> if the parent listener has enabled TCP_SAVE_SYN.
> 
> TCP_SAVED_SYN is read once, it frees the saved SYN headers.
> 
> The data returned in TCP_SAVED_SYN are network (IPv4/IPv6) and TCP
> headers.
> 
> Original patch was written by Tom Herbert, I changed it to not hold
> a full skb (and associated dst and conntracking reference).
> 
> We have used such patch for about 3 years at Google.
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

Applied, but I think you should give maybe a little bit more thought
into the behavior when a not-large-enough buffer is supplied by the
user.

Since we're talking about things on the order of 60 bytes or so at
most, it seems clear to me that signalling an error is probably the
most advisable thing to do in this situation.

Maybe you could signal an error, yet write the actual length to
"optlen".  That way the user can figure out how much they need.  Then
they at least would have the option of retrying with a larger buffer.
--
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