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

Message-id: <20180203011556.GL2220@da0602a-dhcp225.apple.com>
Date:   Fri, 02 Feb 2018 17:15:56 -0800
From:   Christoph Paasch <cpaasch@...le.com>
To:     David Miller <davem@...emloft.net>
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

Hello,

On 01/02/18 - 10:15:46, David Miller wrote:
> 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?

Wrt to the potential performance impact, we have considered using static
keys that would only be enabled if one socket is using an option that is
part of the framework. That way the framework shouldn't cause any
performance issues as long as nobody uses these less common options.

Would that be an option to alleviate such concerns?

Or is your concern here that we are impacting the performance of TCP-MD5?

If it's the latter, we indeed are intentionally trading performance of
TCP-MD5 for a general "cleaner" TCP-stack (one that has no if-statements
for seldom used TCP-options like SMC and MD5). We thought the gain was worth
the cost, which can be arguable of course.

> 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 can see your point and the risk that the abstraction layer brings, but let
me try to clarify what we think the framework would enable:

Our goal with the framework is to optimize/design for the common-case while still
allowing extensibility and less common features.

That way we can keep the TCP-stack clean with the most-used TCP-options (SACK,
Timestamps,...), while still allowing the more exotic features like MD5. And
only sockets that enable TCP-MD5 will pay the potential performance price for
it.

And for new options, the framework forces people to think about how to make the
feature work without spreading if-statements across the stack.
If the new option becomes the common-case after some time, it can always be fully
integrated into the stack at that moment.

> 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.

Would a possible path forward be that we rather post the patches that
cleanup the TCP-MD5 code.
(meaning roughly patches 7 to 14 but without the option-framework adoption)

That way, we cleanup the TCP-stack at least by factoring out TCP-MD5.

> 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.

Point taken, we will double-check our impact on the fast-path and make sure
to change that.

Thanks for your feedback!

Christoph