linux-kernel - Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie

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

Message-ID: <4AED86AD.6010906@gmail.com>
Date:	Sun, 01 Nov 2009 08:01:33 -0500
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	Linux Kernel Developers <linux-kernel@...r.kernel.org>
CC:	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie

Since October 4th, I've repeatedly asked publicly for assistance with these
Linux-specific memory locking constructs and cryptography.  I've also sent
private messages.  No help has been forthcoming.  None.  Nada.

At this point, I've spent weeks re-spinning code that I'd understood was
approved a year ago.  The whole project should have been finished by now!

So, I'll try a larger audience.  Could somebody take a look at my usage of
read and write locking?

NB, I'm trying to port some 15-year-old fairly simple and straightforward
(single cpu) code from the KA9Q cooperative multitasking platform.

I've examined existing code used for syncookies and TCP MD5 authenticators.
Neither meets my needs, as this secret is updated every few minutes.  Both
have very different approaches.  They are rarely used.  My code will be
used on the order of tens of thousands of connections per second.

Moreover, it seems to my naive eye that the syncookie per cpu code simply
doesn't work properly.  The workspace is allocated per cpu, but the cpu
could change during the extensive SHA1 computations.  Bug?

Therefore, I'm approaching this as simply as possible.  I'm particularly
concerned about the initialization and cache state of memory pointers.

Does the locking handle this?  Or is there more to be done?

View attachment "TCPCT+1d.patch" of type "text/plain" (7051 bytes)