Since USB bulk data are terminated by a short fragment there is actually
no need for the URB be long enough for the full message. Provided the
URB are multiples of the USB message size (1k for USB 3) the message
can be received into multiple URB - the driver just has to be willing
to merge URB buffers (as well as split them) when generating the ethernet
frames.
What the driver needs to do us allocate URB with 2k (or 4k) buffers and
only allocate the skb when processing the receive data.
Unfortunately this is a major rework of usb_net.c
Yes, I believe this is the way to go as well.
I have been thinking about it in the context of the cdc_ncm driver. One
problem with the NCM protocol is that it will have to merge all the
buffers of a "NCM Transfer Block" (NTB) before it can process any part
of it. The protocol puts no restrictions on the internal pointers in a
NTB, so there is no guarantee that we can start at the beginning and
work our way towards the end of it. The contained packets can be
interleaved with index(es) or the index can be at the end etc.
But this should still be possible to parse using a list of shorter
buffers to hold each NTB.
Note that some of the usb ethernet drivers allocate large skb then
lie about the truesize.
From: Jim Baxter <hidden> Date: 2014-05-23 11:13:36
On 23/05/14 11:45, David Laight wrote:
From: Bjørn Mork [mailto:bjorn@mork.no]
quoted
David Laight [off-list ref] writes:
...
quoted
quoted
Note that some of the usb ethernet drivers allocate large skb then
lie about the truesize.
Hmm, which drivers are these?
$ grep truesize linux/drivers/net/usb/*
asix_88179_178a, smsc95xx, sr9700.
David
What are the side effects of changing the truesize, if the original
uncloned skb has the full truesize then isn't the potential memory usage
still counted for the avoidance of OOM?
I suppose if the uncloned skb is deleted you would then have a problem
so a chain of URB's would be the safest solution.
Jim
From: Eric Dumazet <hidden> Date: 2014-05-23 13:47:28
On Fri, 2014-05-23 at 12:13 +0100, Jim Baxter wrote:
What are the side effects of changing the truesize, if the original
uncloned skb has the full truesize then isn't the potential memory usage
still counted for the avoidance of OOM?
Nope. This can be disastrous.
A malicious remote peer can crash your host by sending specially cooked
TCP messages.
Send messages with one byte of payload, and out of order so that they
cant be consumed by receiver, and cant be coalesced/collapsed.
If you claim the true size is sizeof(sk_buff) + 512, TCP stack will
accumulate these messages in out of order queue, and will not bother
with them, unless you hit sk_rcvbuf limit.
But in reality these messages uses sizeof(sk_buff) + 32768 bytes.
Divide your physical memory by 32768 : How many such messages will fit
in memory before the host crashes ?
I've seen that kind of attacks in real cases.
Even the fast clones sk_buff mismatch can be noticed. Luckily a 10%
error has no severe impact.
TCP stack uses fast clones, and current stack gives them a truesize of
2048 + sizeof(sk_buff), while it really should be 2048 +
2*sizeof(sk_buff)
Luckily, GSO/TSO tends to reduce the error, as skbs overhead is lower.
From: Jim Baxter <hidden> Date: 2014-05-23 15:01:00
On 23/05/14 14:47, Eric Dumazet wrote:
On Fri, 2014-05-23 at 12:13 +0100, Jim Baxter wrote:
quoted
What are the side effects of changing the truesize, if the original
uncloned skb has the full truesize then isn't the potential memory usage
still counted for the avoidance of OOM?
Nope. This can be disastrous.
A malicious remote peer can crash your host by sending specially cooked
TCP messages.
Send messages with one byte of payload, and out of order so that they
cant be consumed by receiver, and cant be coalesced/collapsed.
If you claim the true size is sizeof(sk_buff) + 512, TCP stack will
accumulate these messages in out of order queue, and will not bother
with them, unless you hit sk_rcvbuf limit.
But in reality these messages uses sizeof(sk_buff) + 32768 bytes.
Divide your physical memory by 32768 : How many such messages will fit
in memory before the host crashes ?
I've seen that kind of attacks in real cases.
Even the fast clones sk_buff mismatch can be noticed. Luckily a 10%
error has no severe impact.
TCP stack uses fast clones, and current stack gives them a truesize of
2048 + sizeof(sk_buff), while it really should be 2048 +
2*sizeof(sk_buff)
Luckily, GSO/TSO tends to reduce the error, as skbs overhead is lower.
From: David Laight <hidden> Date: 2014-05-23 15:31:36
From: Eric Dumazet
...
TCP stack uses fast clones, and current stack gives them a truesize of
2048 + sizeof(sk_buff), while it really should be 2048 +
2*sizeof(sk_buff)
Luckily, GSO/TSO tends to reduce the error, as skbs overhead is lower.
Doesn't that affect the tx side - where the truesize doesn't matter as much?
David
From: Eric Dumazet <hidden> Date: 2014-05-23 15:41:39
On Fri, 2014-05-23 at 15:30 +0000, David Laight wrote:
From: Eric Dumazet
...
quoted
TCP stack uses fast clones, and current stack gives them a truesize of
2048 + sizeof(sk_buff), while it really should be 2048 +
2*sizeof(sk_buff)
Luckily, GSO/TSO tends to reduce the error, as skbs overhead is lower.
Doesn't that affect the tx side - where the truesize doesn't matter as much?
Its not a matter of tx or rx, but percentage of error.
If truesize accounting is wrong by 10%, its not a big deal, because we
normally limit tcp_mem[] to about 16% of available physical memory.
Using 16% of physical memory instead of 16% should not really matter.
Now, if the truesize is wrong by 1600%, then its pretty clear we can
consume all the meory.