netdev - RE: [RFC PATCH net-next 0/3] sctp: add GSO support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Jan 2016 15:57:59 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Marcelo Ricardo Leitner' <marcelo.leitner@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Neil Horman <nhorman@...driver.com>,
	Vlad Yasevich <vyasevich@...il.com>,
	David Miller <davem@...emloft.net>,
	"brouer@...hat.com" <brouer@...hat.com>,
	"alexander.duyck@...il.com" <alexander.duyck@...il.com>,
	"alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
	"borkmann@...earbox.net" <borkmann@...earbox.net>,
	"marek@...udflare.com" <marek@...udflare.com>,
	"hannes@...essinduktion.org" <hannes@...essinduktion.org>,
	"fw@...len.de" <fw@...len.de>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"john.r.fastabend@...el.com" <john.r.fastabend@...el.com>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [RFC PATCH net-next 0/3] sctp: add GSO support

From: 'Marcelo Ricardo Leitner'
> Sent: 28 January 2016 20:56
...
> > > > I did wonder whether the queued data could actually be picked up
> > > > be a Heartbeat chunk that is probing a different remote address
> > > > (which would be bad news).
> > >
> > > I don't follow. You mean if a heartbeat may get stuck in queue or if
> > > sending of a heartbeat can end up carrying additional data by accident?
> >
> > My suspicion was that the heartbeat would carry the queued data.
> 
> I'm afraid I'm  still not following, sorry. You mean that this GSO patch
> would cause the heartbeat to carry queued data? If yes, no, because for
> SCTP side of it it mangles the packet size and make it look bigger
> instead of handling multiple packets. It will then break this large
> sctp_packet into several sk_buff and glue them together as if they were
> GROed, allowing skb_segment to just split them back. The reason the
> sctp_packet is generated, being it due to user data or control chunks
> like heartbeats, is not modified.

I'm thinking of the code prior to your GSO changes.

IIRC with nagle enabled data chunks are built and put onto an
internal queue to be sent later (with nagle disabled they are
sent at the end of the tx processing provided (IIRC) there is window).
Any message that forces a transmit picks up the queued data - and
I think this might include heartbeats....

I didn't read the code closely enough to find out whether this
was true or not.

	David