netdev - Re: [PATCH net-next v4 04/15] mctp: Add sockaddr

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: <df5c3b8c0d0e8e2c97d4ab009c2f8faf1569c958.camel@codeconstruct.com.au>
Date:   Fri, 15 Oct 2021 09:18:45 +0800
From:   Jeremy Kerr <jk@...econstruct.com.au>
To:     Eugene Syromiatnikov <esyr@...hat.com>
Cc:     netdev@...r.kernel.org, Matt Johnston <matt@...econstruct.com.au>,
        Andrew Jeffery <andrew@...id.au>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        linux-m68k@...ts.linux-m68k.org
Subject: Re: [PATCH net-next v4 04/15] mctp: Add sockaddr_mctp to uapi

Hi Eugene,

Thanks for taking a look at these!

> > +typedef __u8                   mctp_eid_t;
> > +
> > +struct mctp_addr {
> > +       mctp_eid_t              s_addr;
> > +};
> > +
> >  struct sockaddr_mctp {
> > +       unsigned short int      smctp_family;
> 
> This gap makes the size of struct sockaddr_mctp 2 bytes less at least
> on m68k, are you fine with that?

Yep, that's OK from the protocol implementation side; this layout better
matches the "hierarchy" of the MCTP addressing. If we go for optimal
packing, the order of the members makes somewhat less sense. We could
add padding members, but I'm not sure that's worth it...

I noticed a few other protocol implementations doing similar things, so
assume it isn't an issue - it's all arch-specific ABI anyway, right?

> > +       int                     smctp_network;
> > +       struct mctp_addr        smctp_addr;
> > +       __u8                    smctp_type;
> > +       __u8                    smctp_tag;
> >  };

Cheers,


Jeremy