netdev - Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames

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

Date:   Mon, 22 Feb 2021 00:56:56 -0800
From:   Xie He <xie.he.0141@...il.com>
To:     Martin Schiller <ms@....tdt.de>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Leon Romanovsky <leon@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Linux X25 <linux-x25@...r.kernel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Krzysztof Halasa <khc@...waw.pl>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames

On Sun, Feb 21, 2021 at 11:14 PM Martin Schiller <ms@....tdt.de> wrote:
>
> I'm not really happy with this change because it breaks compatibility.
> We then suddenly have 2 interfaces; the X.25 routings are to be set via
> the "new" hdlc<x>_x25 interfaces instead of the hdlc<x> interfaces.
>
> I currently just don't have a nicer solution to fix this queueing
> problem either. On the other hand, since the many years we have been
> using the current state, I have never noticed any problems with
> discarded frames. So it might be more a theoretical problem than a
> practical one.

This problem becomes very serious when we use AF_PACKET sockets,
because the majority of frames would be dropped by the hardware
driver, which significantly impacts transmission speed. What I am
really doing is to enable adequate support for AF_PACKET sockets,
allowing users to use the bare (raw) LAPB protocol. If we take this
into consideration, this problem is no longer just a theoretical
problem, but a real practical issue.

If we don't want to break backward compatibility, there is another option:
We can create a new API for the HDLC subsystem for stopping/restarting
the TX queue, and replace all HDLC hardware drivers' netif_stop_queue
and netif_wake_queue calls with calls to this new API. This new API
would then call hdlc_x25 to stop/restart its internal queue.

But this option would require modifying all HDLC hardware drivers'
code, and frankly, not all HDLC hardware drivers' developers care
about running X.25 protocols on their hardware. So this would cause
both hardware driver instabilities and confusion for hardware driver
developers.