netdev - Re: [PATCH net-next 3/5] sctp: add spp_ipv6_flowlabel and spp_dscp for sctp

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: <CAPA1RqB48gBWKOQck6Ke5yH3cm1B5QtJKh1CL4SYfqes8Tc+Nw@mail.gmail.com>
Date:   Tue, 26 Jun 2018 01:12:00 +0900
From:   吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     Neil Horman <nhorman@...driver.com>,
        David Miller <davem@...emloft.net>, lucien.xin@...il.com,
        netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
        吉藤英明 <hideaki.yoshifuji@...aclelinux.com>,
        yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next 3/5] sctp: add spp_ipv6_flowlabel and spp_dscp
 for sctp_paddrparams

Hi,

2018-06-25 22:03 GMT+09:00 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>:
> On Mon, Jun 25, 2018 at 07:28:47AM -0400, Neil Horman wrote:
>> On Mon, Jun 25, 2018 at 04:31:26PM +0900, David Miller wrote:
>> > From: Xin Long <lucien.xin@...il.com>
>> > Date: Mon, 25 Jun 2018 10:14:35 +0800
>> >
>> > >  struct sctp_paddrparams {
>> > > @@ -773,6 +775,8 @@ struct sctp_paddrparams {
>> > >   __u32                   spp_pathmtu;
>> > >   __u32                   spp_sackdelay;
>> > >   __u32                   spp_flags;
>> > > + __u32                   spp_ipv6_flowlabel;
>> > > + __u8                    spp_dscp;
>> > >  } __attribute__((packed, aligned(4)));
>> >
>> > I don't think you can change the size of this structure like this.
>> >
>> > This check in sctp_setsockopt_peer_addr_params():
>> >
>> >     if (optlen != sizeof(struct sctp_paddrparams))
>> >             return -EINVAL;
>> >
>> > is going to trigger in old kernels when executing programs
>> > built against the new struct definition.
>
> That will happen, yes, but do we really care about being future-proof
> here? I mean: if we also update such check(s) to support dealing with
> smaller-than-supported structs, newer kernels will be able to run
> programs built against the old struct, and the new one; while building
> using newer headers and running on older kernel may fool the
> application in other ways too (like enabling support for something
> that is available on newer kernel and that is not present in the older
> one).

We should not break existing apps.
We still accept apps of pre-2.4 era without sin6_scope_id
(e.g., net/ipv6/af_inet6.c:inet6_bind()).

>
>> >
>> I think thats also the reason its a packed aligned attribute, it can't be
>> changed, or older kernels won't be able to fill it out properly.
>> Neil
>
> It's more for supporting running 32-bits apps on 64-bit kernels
> (according to 20c9c825b12fc).
>
>   Marcelo