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
| ||
|
Date: Fri, 17 Aug 2012 11:15:44 -0700 From: Yuchung Cheng <ycheng@...gle.com> To: David Laight <David.Laight@...lab.com> Cc: davem@...emloft.net, hkchu@...gle.com, edumazet@...gle.com, ncardwell@...gle.com, sivasankar@...ucsd.edu, netdev@...r.kernel.org Subject: Re: [PATCH v2 0/7] TCP Fast Open client On Thu, Aug 16, 2012 at 1:50 AM, David Laight <David.Laight@...lab.com> wrote: > This comment is a bit late but ... > >> ... >> This patch series implement the client functionality of TCP Fast Open. >> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK >> packets and consumed by the receiving end during the initial > connection >> handshake, thus providing a saving of up to one full round trip time >> (RTT) >> compared to standard TCP requiring a three-way handshake (3WHS) to >> complete before data can be exchanged. >> ... >> To use Fast Open, the client application (active SYN sender) must >> replace connect() socket call with sendmsg() or sendto() with the new >> MSG_FASTOPEN flag. If the server supports Fast Open the data exchange >> starts at TCP handshake. Otherwise the connection will automatically >> fall back to conventional TCP. > > It seems wrong to be using sendmsg() to perform a 'connect' action. > Anything that tries to monitor the socket state from a trace, or > validate the sequence of library calls will get it all wrong. > > IMHO this should be a new connect_xxx() function - and probably > a new system call entry. > > This is similar to the complete fubar where sctp abuses setsockopt(). > > For development hacking using sendmsg() probably avoided the need > to hack at some code paths, but I'm sure it will cause grief in > the long term. > > Other OS may have much more difficultly in abusing sendmsg(). User/developers' feedback are always welcome so thanks for that. First of all, sendmsg(MSG_FASTOPEN) does not exclude a new socket call like connect_with_data(). Unlike many TCP features that don't require API change, TFO does. When we started, we have several non-exclusive choices: a) connect_xxx() like you proposed b) send{to|msg}(MSG_FASTOPEN) c) setsockopt(optval=data) d) setsockopt(optval=TFO), make connect() a nop, first write() sends SYN+data. We surveyed existing works and also discussed with a few developers before landing on (b). For example, R. Stevens implemented the pioneer work T/TCP with sendto(MSG_EOF) in BSD in his TCP/IP illustrated vol3. There is also a Linux patch too. So we know at least (b) is a viable route. Chrome browser developers chose (b) and quickly modified the browser accordingly to support TFO. Another benefit of sendmsg is it allows vector writes right away and may support MSG_EOF in the future (connect()+write()+close()=SYN+data+FIN). Most importantly, we want to minimize the application change in the hope of broader usage to collect more feedbacks about TFO. If many developers think a new connect() API is better, it's not that difficult to add one in the kernel IMO. I am happy to do try that. Cheers, Yuchung > > David > > > -- 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