linux-kernel - Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

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:   Wed, 28 Sep 2016 15:45:20 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
        dsa@...ulusnetworks.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kuznet@....inr.ac.ru,
        jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
        avagin@...nvz.org, stephen@...workplumber.org
Subject: Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On Wed, Sep 28, 2016 at 08:27:24AM -0400, Jamal Hadi Salim wrote:
> > 
> > They must initialize it to zero.
> > 
> 
> What if in the future actually meant to use 0 for
> something?;-> For example in Cyrill's case it means PROTO_IP
> Not sure if it useful to interpret or not but it is part of the
> enum for protocols.

It will be perfectly fine if we start using 0 here for something,
the main match key is @sdiag_proto (which will be IPPROTO_RAW for
my case). If someone is to use this field for something else the
main key selection remain the same, iow @sdiag_proto first and
then subprotocol if needed.

> Maybe we shouldnt be adding pad fields in these netlink
> structure definitions then one can liberally add new ones.

You know, I personally don't see much problem in defining union,
especially while anonymous uninons do work for us here.

> Note: inet_diag somewhere has a netlink structure that
> has a hole. I pointed it out to Eric D. and he said we cant
> add it now because it would break ABI.

Naming holes generated by a compiler for alignment sake should
not break abi (because alignments are abi by self), but I may
be missing something in context of where the structure you're
talking about is present. And what about non-x86 archs? They
might have different members alignment requirements.

> So where do we draw the line for future extensions?