netdev - Re: [PATCH net-next v6] net: openvswitch: IPv6: Add IPv6 extension header support

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]

Message-ID: <CAASuNyW81zpSu+FGSDuUrOsyqJj7SokZtvX081BbeXi0ARBaYg@mail.gmail.com>
Date:   Fri, 1 Oct 2021 13:42:32 -0700
From:   Cpp Code <cpp.code.lv@...il.com>
To:     Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        pshelar@....org, "David S. Miller" <davem@...emloft.net>,
        ovs dev <dev@...nvswitch.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v6] net: openvswitch: IPv6: Add IPv6 extension
 header support

On Fri, Oct 1, 2021 at 12:21 AM Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
>
> Le 30/09/2021 à 18:11, Cpp Code a écrit :
> > On Wed, Sep 29, 2021 at 6:19 AM Jakub Kicinski <kuba@...nel.org> wrote:
> >>
> >> On Wed, 29 Sep 2021 08:19:05 +0200 Nicolas Dichtel wrote:
> >>>> /* Insert a kernel only KEY_ATTR */
> >>>> #define OVS_KEY_ATTR_TUNNEL_INFO    __OVS_KEY_ATTR_MAX
> >>>> #undef OVS_KEY_ATTR_MAX
> >>>> #define OVS_KEY_ATTR_MAX            __OVS_KEY_ATTR_MAX
> >>> Following the other thread [1], this will break if a new app runs over an old
> >>> kernel.
> >>
> >> Good point.
> >>
> >>> Why not simply expose this attribute to userspace and throw an error if a
> >>> userspace app uses it?
> >>
> >> Does it matter if it's exposed or not? Either way the parsing policy
> >> for attrs coming from user space should have a reject for the value.
> >> (I say that not having looked at the code, so maybe I shouldn't...)
> >
> > To remove some confusion, there are some architectural nuances if we
> > want to extend code without large refactor.
> > The ovs_key_attr is defined only in kernel side. Userspace side is
> > generated from this file. As well the code can be built without kernel
> > modules.
> > The code inside OVS repository and net-next is not identical, but I
> > try to keep some consistency.
> I didn't get why OVS_KEY_ATTR_TUNNEL_INFO cannot be exposed to userspace.

OVS_KEY_ATTR_TUNNEL_INFO is compressed version of OVS_KEY_ATTR_TUNNEL
and for clarity purposes its not exposed to userspace as it will never
use it.
I would say it's a coding style as it would not brake anything if exposed.

>
> >
> > JFYI This is the file responsible for generating userspace part:
> > https://github.com/openvswitch/ovs/blob/master/build-aux/extract-odp-netlink-h
> > This is the how corresponding file for ovs_key_attr looks inside OVS:
> > https://github.com/openvswitch/ovs/blob/master/datapath/linux/compat/include/linux/openvswitch.h
> > one can see there are more values than in net-next version.
> There are still some '#ifdef __KERNEL__'. The standard 'make headers_install'
> filters them. Why not using this standard mechanism?

Could you elaborate on this, I don't quite understand the idea!? Which
ifdef you are referring, the one along OVS_KEY_ATTR_TUNNEL_INFO or
some other?

>
> In this file, there are two attributes (OVS_KEY_ATTR_PACKET_TYPE and
> OVS_KEY_ATTR_ND_EXTENSIONS) that doesn't exist in the kernel.
> This will also breaks if an old app runs over a new kernel. I don't see how it
> is possible to keep the compat between {old|new} {kernel|app}.

Looks like this most likely is a bug while working on multiple
versions of code.  Need to do add more padding.

>
>
> Regards,
> Nicolas