Mailing List Archive

Hi,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> writes:
>
>Hello!
>> Is this right?
>
>It is right, but not quite right. TCP is pretty insensitive
>to allocated memory in xmit direction. If driver queues
>more than one or two packets, it breaks TCP not depending
>on memory commitments.
>
>UDP is really sensitive.
I analyzed the path that an skb travels through the isdn driver.
With single link ppp, the isdn_ppp might queue at most one frame
internally. The hisax isdn hardware level driver has an additional
xmit queue which is limited by 4kB payload. Thus, with MTU 1500, the isdn
internal queue length will not exceed 3-4 packets.
It was not very difficult to add passing the skb's ownership when they were
copied or cloned inside the isdn driver (at least for single link ppp).
Given the analysis above, is it worthy to commit such (skb ovnership passing)
changes or will it just complicate the driver code for very little gain?
Another question: Is the optimal txqueuelen to be configured for the
network interface somehow related to the length of the driver
internal queue?
>
>> with ppp and isdn_ppp links. (Maybe it even allows for a denial-of-service
>> exploit by sending large amounts of data through a udp socket to a
>> destination which is routed through a compressed ppp link.
>
>Do you want to say, queue size in not limited at all? 8)
I was suspecting such a bug (an unlimited queue),
but fortunatly, it turned out that I was wrong.
>Nice. It has nothing to do with socket memory accounting.
I think socket accounting will probably protect a user from filling up an
unlimited queue by accident. But exploits would still be prossibe
(e.g. by filling the queue not directly from a socket but through
another network interface such that the packets are routed through
the defective device).
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Hello!
> xmit queue which is limited by 4kB payload. Thus, with MTU 1500, the isdn
> internal queue length will not exceed 3-4 packets.
Yes, it is OK. Actually, the counting depends on link speed.
If it is enough high to hold rtt for MTU sized frame <= 200msec,
it is better not to violate this bound. If it is so low, that
this bound cannot be achieved in any case, it should be selected
so that queue_size/rate enough to make ssh/telnet more-or-less responsive.
> Given the analysis above, is it worthy to commit such (skb ovnership passing)
> changes or will it just complicate the driver code for very little gain?
Well, it is not so complicated. However, with small queue_size/rate
effect of such change is visible only if TCP window is set to small
value < queue_size (counting overhead).
> Another question: Is the optimal txqueuelen to be configured for the
> network interface somehow related to the length of the driver
> internal queue?
No. Actually, ideal variant is when driver holds the lowest possible
number of queued packets. It is 1 for slow drivers or higher number
for fast one. F.e. 2 is enough for 10Mbit ethernet, 16 is enough
for 100Mbit one.
> I think socket accounting will probably protect a user from filling up an
> unlimited queue by accident.
Alas, it will not.
for (;;) {
s = socket(AF_INET, SOCK_DGRAM, 0);
sendto(s, ...);
close(s);
}
will kill machine reliably and almost instantly, if driver queue
is unlimited.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Alexey <kuznet@ms2.inr.ac.ru> writes:
>Hello!
>> xmit queue which is limited by 4kB payload. Thus, with MTU 1500, the isdn
>> internal queue length will not exceed 3-4 packets.
>
>Yes, it is OK. Actually, the counting depends on link speed.
>If it is enough high to hold rtt for MTU sized frame <= 200msec,
>it is better not to violate this bound. If it is so low, that
>this bound cannot be achieved in any case, it should be selected
>so that queue_size/rate enough to make ssh/telnet more-or-less responsive.
But ISDN B channel only provides 64000 Bit/s. Thus, according to your
200 msec rule, we should never have more than one frame inside the driver
in order to fulfill this critereon with MTU 1500.
not queue (minus overhead for hdlc framing)
>> I think socket accounting will probably protect a user from filling up an
>> unlimited queue by accident.
>
>Alas, it will not.
>
>for (;;) {
> s = socket(AF_INET, SOCK_DGRAM, 0);
> sendto(s, ...);
> close(s);
>}
>
>will kill machine reliably and almost instantly, if driver queue
>is unlimited.
Sure! (I was aware of this, but consideed it to be an exploit rather than
an accident).
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/