netdev - problems with SCTP GSO

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]

Date:   Mon, 11 Jun 2018 20:29:05 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     marcelo.leitner@...il.com
CC:     lucien.xin@...il.com, edumazet@...gle.com, netdev@...r.kernel.org
Subject: problems with SCTP GSO

I would like to bring up some problems with the current GSO
implementation in SCTP.

The most important for me right now is that SCTP uses
"skb_gro_receive()" to build "GSO" frames :-(

Really it just ends up using the slow path (basically, label 'merge'
and onwards).

So, using a GRO helper to build GSO packets is not great.

I want to make major surgery here and the only way I can is if
it is exactly the GRO demuxing path that uses skb_gro_receive().

Those paths pass in the list head from the NAPI struct that initiated
the GRO code paths.  That makes it easy for me to change this to use a
list_head or a hash chain.

Probably in the short term SCTP should just have a private helper that
builds the frag list, appending 'skb' to 'head'.

In the long term, SCTP should use the page frags just like TCP to
append the data when building GSO frames.  Then it could actually be
offloaded and passed into drivers without linearizing.