netdev - Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data

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] [day] [month] [year] [list]

Date:	Mon, 05 Oct 2009 13:42:54 -0400
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data

David Miller wrote:
> Then we'll eat an atomic operation every connect() or something
> like that?
> 
Yes, on the client side.  On the server side, I was trying to avoid any
until after a 3-way handshake (the reason that I removed the kref'd struct
in Adam's request sock).

Adam:
+	struct tcp_sadata_payload	*sadata_payload;
+	u8				sadata_nonce[4]; /* generated nonce */
+	u8				sadata_ok:1;   /* send sadata?    */

Mine:
+	u8				*cookie_copy;	/* temporary pointer */
+	u8				cookie_size;	/* bytes in copy */
+	u8				s_data_in:1,
+					s_data_out:1,
+					cookie_in_always:1,
+					cookie_out_never:1;

Mine makes the code more tricky, though.  I'm depending on the various
locks and hashes to keep things kosher, whereas Adam kept more kref'd
pointer instances lying around for a longer time.  Tradeoffs....

But I *was* patting myself on the back for saving 3 bytes here.  ;-)

> That's bad too.  We're trying desperately to remove as many
> atomic operations as possible from the socket paths.
> 
And Adam had done a good job, too.  The state has to go somewhere!

After all, I've plenty of experience with small TCP implementations, as
*all* implementations were constrained back in the day.  At least one of
my tiny TCP/IP/PPP stack implementations is in hundreds of millions of
cell phones (originally on 186s with only a few K of RAM).

> Compress your state, really compress it, don't just externalize
> it somewhere else in exchange for a different cost.
> 
Cookies are pseudo-random nonces, not compressible by definition.

I think I'll be able to join everything into a single kref'd block, with
some modification/reuse of various function md5sig parameters to pass
pointers....  Cookie nonces are redundant to the authenticator option(s),
so they're never around at the same time.

That will whittle the tcp_sock size down some more, although it could
increase the overall memory footprint, as there will be wasted space for
the case where there are cookies without SYN data.  By keeping the sizes
and flags in the sock itself, both Adam and I were optimizing performance.

It's just tradeoffs, always and forever tradeoffs.
--
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