linux-kernel - Re: [PATCH] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header

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:   Tue, 28 Jul 2020 18:41:45 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Brian Norris <briannorris@...omium.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux X25 <linux-x25@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header_len

Thank you for your detailed review, Brian!

I guess we have the same understanding on the "hard_header_len vs
needed_headroom" part. I agree it is not well documented and is also
confusing to driver developers. I didn't understand it either until I
looked at af_packet.c.

On Tue, Jul 28, 2020 at 12:52 PM -0700
Brian Norris <briannorris@...omium.org> wrote:
>
> What's to say you shouldn't be implementing header_ops instead? Note
> that with WiFi drivers, they're exposing themselves as ARPHRD_ETHER, and
> only the Ethernet headers are part of the upper "protocol" headers. So
> my patch deferred to the eth headers.
>
> What is the intention with this X25 protocol? I guess the headers added
> in lapbeth_data_transmit() are supposed to be "invisible", as with this
> note in af_packet.c?
>
>    - if device has no dev->hard_header routine, it adds and removes ll header
>      inside itself. In this case ll header is invisible outside of device,
>      but higher levels still should reserve dev->hard_header_len.
>
> If that's the case, then yes, I believe this patch should be correct.

This driver is not intended to be used with IPv4 or IPv6 protocols,
but is intended to be used with a special "X.25" protocol. That's the
reason the device type is ARPHRD_X25. I used "grep" in the X.25
network layer code (net/x25) and I found there's nowhere
"dev_hard_header" is called. I also used "grep" in all the X.25
drivers in the kernel (lapbether.c, x25_asy.c, hdlc_x25.c under
drivers/net/wan) and I found no driver implemented "header_ops". So I
think the X.25 networking code doesn't expect any header visible
outside of the device driver, and X.25 drivers should make their
headers invisible outside of them.

So I think hard_header_len should be 0 for all X.25 drivers, so that
they can be used correctly with af_packet.c.

I don't know if this sounds plausible to you. If it does, could you
please let me have your name in a "Reviewed_by" tag. It would be of
great help to have your support. Thanks!