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] [day] [month] [year] [list]
Message-ID: <CA+FuTSdF9p4Y61Ceucdg9OUT5nv+ieVUy7Rzkq6TUYc532jHCg@mail.gmail.com>
Date:   Thu, 15 Oct 2020 15:56:45 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Xie He <xie.he.0141@...il.com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        syzbot <syzbot+4a2c52677a8a1aa283cb@...kaller.appspotmail.com>,
        William Tu <u9012063@...il.com>
Subject: Re: [Patch net v2] ip_gre: set dev->hard_header_len and
 dev->needed_headroom properly

On Thu, Oct 15, 2020 at 3:19 PM Xie He <xie.he.0141@...il.com> wrote:
>
> On Thu, Oct 15, 2020 at 6:42 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > On Wed, Oct 14, 2020 at 10:25 PM Xie He <xie.he.0141@...il.com> wrote:
> > >
> > > Actually I think dev->type can be seen from user space. For example,
> > > when you type "ip link", it will display the link type for you. So I
> > > think it is useful to keep different dev->type labels without merging
> > > them even if they appear to have no difference.
> >
> > Ah, indeed. These constants are matched in iproute2 in lib/ll_types.c
> > to string representations.
> >
> > Good catch. Yes, then they have to stay as is.
>
> So in this case it may be better to keep dev->type as ARHPHRD_IPGRE
> for GRE devices with or without header_ops. This way we can avoid the
> need to update iproute2.
>
> We can still consider changing GRE devices in collect_md mode from
> ARPHRD_NONE to ARHPHRD_IPGRE. The original author who changed it to
> ARPHRD_NONE might assume ARHPHRD_IPGRE is for GRE devices with
> header_ops, so he felt he needed to distinguish GRE devices without
> header_ops by dev->type. However, ARHPHRD_IPGRE is actually already
> used for GRE devices with header_ops AND without header_ops. So it
> doesn't hurt to use ARHPHRD_IPGRE for GRE devices in collect_md mode,
> too. This would also make iproute2 to correctly display GRE devices in
> collect_md mode as GRE devices.

That's true. Whenever you make user visible changes there is some
chance of breakage. I'm not sure it's worth the risk here. The present
state is perhaps not ideal, but not broken.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ