netdev - Re: [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5

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:   Thu, 01 Feb 2018 10:15:46 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     cpaasch@...le.com
Cc:     netdev@...r.kernel.org, edumazet@...gle.com,
        mathew.j.martineau@...ux.intel.com
Subject: Re: [RFC v2 00/14] Generic TCP-option framework and adoption for
 TCP-SMC and TCP-MD5

From: Christoph Paasch <cpaasch@...le.com>
Date: Wed, 31 Jan 2018 16:07:02 -0800

> TCP-options like TCP_MD5 and SMC are rather rare use-cases, but their
> implementation is rather intrusive to the TCP-stack. Other, more recent
> TCP extensions like TCP-crypt, MPTCP or TCP-AO would make this situation
> even worse.

Yet, this current implementation is what allows us to optimize things
properly.

And now we're going to do indirect calls to callbacks instead of
inline tests as well?

Also, requiring such direct surgery for new TCP options forces the
developer to consider the consequences of what the new TCP option
does and how it effect both the slow and the fast path.

With abstraction layers, people tend to turn their brains off when
it comes to these issues.

Sorry, I'm really not thrilled about this.

I would rather see the new TCP option features be proposed using
the existing code and then see how it all can be abstracted away
after they are all added.

I can already see in your patches that new overhead is added, new
tests in the packet building fast paths that are completely
unnecessary with the existing code, etc.